RTLight Emiting Entity

[KillPixel]

Does anyone here have experience creating an item that gives off light, such as a health pickup or torch, in darkplaces?

If so, plz share your secrets

[Cobalt]

Yep, in DP there is an extension to apply light to any ent, its called:

TENEBRAE_GFX_DLIGHTS

Basicly emit a light any color / intensity. Unfortunately a drawback is the angle its aimed is read right from the models angles field...which means most models that change angles , the angle will stay at 0. This extension also can make use of lightstyles that are already defined , such as the ones that ficker for the torches.

For healths , they happen to be BSP models so when you compile them, you are more or less making a little map and have to bake in the light just like you would with a map.

Also you have the .effects field in QC where you can set a DIM or Bright light effect, as well as some new values to make quads glow blue and pents glow red (EF_BLUE & EF_RED respectively.

Oh and one more field is .modelflags, where a value of 64 will make it emit an orange glow and I believe 128 will make it emit purple, which is more or less like combining effects fields EF_RED and EF_BLUE together (EF_PURPLE so to speak).

[KillPixel]

Thanks Cobalt, it looks like TENEBRAE_GFX_DLIGHTS is exactly what I need.

I've only recently began to look at QC so I have no experience with it and my comprehension of it is very weak.

Could you show me how this would be implemented? This the code I have (just a Quake healthbox with a different model):

{
precache_model("progs/health.spr32");
precache_sound("items/health1.wav");
setmodel(self, "progs/health.spr32");
self.noise = "items/health1.wav";
self.healamount = 15;
self.healtype = 1;
}

I see all the available fields in dpextension.qc but, as I said, I have no idea how to implement the code.

EDIT: Ok, I managed to *somehow* cobble some code together that does something. The item emits light but it doesn't appear on the floor, but it does on the walls around it (.vector angles?). The part that is unexpected is that the light persists even after the item has been picked up. Still chipping away at it...

[Cobalt]

Haha Cute pix!

Yea sounds like you got it, and because the angles field represents the models angles, it means whatever anfle the model is at will be the orientation of that emitted light. Its a drawback I have mentioned to Lord Havoc who so far has not answered.

Yea the light will stay because your pickup technicly is not removed, it just now has a null model ("") , so you will have to put in some code that turns off the light_lev when its touched and the model changes.

In my mod I have the wall torches set to modelflags = 64, and they show a orange light around them, however since its a modelflag, the light is only visible depending on the clients PVS/Field of view. You have to be pretty close for it to be active. You can also apply TENEBRAE_GFX_DLIGHTS to these...and create new lightstyles in world.qc that represent new flicker rates. The drawback I found was all the baked in light sources in the map that have the old lightstyles have to be eliminated...so a small amount of things on some maps will no longer have the light. In "Darkplaces" this is not much a big deal tho...


If you look in dpextensions.qc these lights can also use Cubemaps. Cubemaps seem to be sort of like skin files (projective light filter) as they say. I know DPmod has some files in a cubemaps folder and I have meant to experiment with them myself but have not. Apparently you can alter the light perhaps like through a lense or something. Since it uses the .skin field, turns out it could conflict with the skin the ent uses depending on the mod.

[Spike]

the diffuse lighting term is a function of dotproduct(surfacenormal,directiontolight), thus if your light is too close to the ground, the diffuse term is unlikely to contribute any light at all.
unfortunately, the TENEBRAE-esque extension does not support changing the ambient/diffuse intensities, and thus you're unable to configure the light to use ambient=1,diffuse=0 on a per-light basis.
you should be able to reconfigure these two cvars though: r_shadow_realtime_dlight_ambient=1,r_shadow_realti me_dlight_diffuse=0.
(note that it is possible to configure it per-light using fte's csqc dynamiclight_add and dynamiclight_set builtins to reconfigure the rt-dlight).

alternatively, just make your item's min_z more negative than it already is, to move the object off the ground allowing it to actually light something.

The angles field can affect the light's cubemaps (and maybe the orientation of the shadowmaps, but this should only be a precision difference), and thus should not affect the lighting levels at all of a light which does not use cubemaps (.skin selects the numbered cubemap with the TENEBRAE_ extension, not used = angle makes no difference).

[damage_inc]

Sort of off topic but still about lighting...

Is it possible to have either RT or dynamic lighting that "moves"? As an example a red "circular" flashing siren, is it possible? And in what engine would be best to create such an effect?

I'm just curious.

[Cobalt]

Ya possible. I stumbled on something exactly that same effect with proximity mines. I have the mine set as the grenade model about 10 units above the floor and have it rotating via avelocity_y at some value, then its doing a .think and in the think function I have its .effects field set to muzzleflash. Turns out I guess that effect sets the light at I think one of its corners so it looks like its aimed outward.

Sort of off topic but still about lighting...

Is it possible to have either RT or dynamic lighting that "moves"? As an example a red "circular" flashing siren, is it possible? And in what engine would be best to create such an effect?

I'm just curious.

[xaGe]

I do love that effect. It works rather well.

Ya possible. I stumbled on something exactly that same effect with proximity mines.