Ambient light (dynamic) in FTEQW

[toneddu2000]

There's a way to create a dynamic ambient light in FTEQW? For ambient light I mean an overall non-specular light that could or couldn't (better couldn't) project shadows but that gives a subtle (or not so subtle, it depends on how much you increase it)illumination, that, combined with point lights, gives a nice result. Because, to simulate this effect, I'm forced to use many lights (10 or so) and fte doesn't seem to like them (framerate drops from 200/250 frames to 40/60 frames per second).
I don't want to use lightmaps but only dynamic lights.

My workflow is (I don't know if it's the correct one) to create lights in NetRadiant and build BSP + VIS passes (no light pass) and to open map in FTEQW and dynamics lights are already there because r_editlights_import_diffuse and speculare set to 1

r_editlights_import_ambient set to 1 with just one light doesn't give a nice result because point light is directional and, it floods (as it should) the area where it is but leaves black the areas where radius falloffs.

cvar ambient_level and ambient_fade seem to be ambient sound cvars

Questions to Spike:
1) I saw in fte src that there's a cvar named r_ambient but I tried to digit it but it doesn't exist
2) Any plan to add dynamic global illumination in FTEQW? That would be a GREAT addition!
3) There's a way to exclude some dynamic point light to project specular light (project only diffuse light)?

The ideal method would be (imho) to create a group entity in NetRadiant that covers the entire area where I need the area ambient light (in my case, the entire map) and, in quakec, to set the ambient light via pflags, but WITHOUT radius. COuld it be feasible?

Thanks guys

[frag.machine]

[Spike]

csaddon's light editor provides separate ambient/diffuse/specular scalers.

if you actually care about performance, you would set r_shadow_realtime_world to 1 and then have your rtlights be additive to that.
then you can use whatever ugly minlight settings you want without it exhibiting bumpmaps from the other side of the map. it'll be ugly, of course.

[toneddu2000]

[Spike]

if you're making a TC:
r_editlights_import_radius 0
r_shadow_realtime_world_lightmaps 1
then your rtlights are additive.

the great thing about lightmaps is that you can use radiance algorithms, with backscatter and all sorts of other refinements.
rtlights on the other hand are simple spheres of light. they're just a realtime equivelent of vanilla quake. Sure they contribute to bumpmaps and stuff, but the overall light levels are not fantastically different from quake.
they cannot bounce around corners.
if you enable deluxemapping (in both engine and map compiler), you should be able to attain nicer looking lighting without needing to resort to the expense of rtlights.

the problem with importing lights from your map editor is that the rules for those lights are identical to both and thus you just get doubled light rather than anything more useful.

ideally you would use spotlights in preference to omni-lights, whereever practical. regular 'omni' lights need to generate 6 different shadowmaps every single frame, while spotlights need only 1.
alternatively, use shadowless rtlights, as these don't need to cast any shadows at all.

make sure your glsl uses the SKELETAL permutation. if your glsl does not provide this, your skeletal models will be animated on the cpu.
don't underestimate the cost of offsetmapping.

you can write some csqc to read the entity lump clientside and emit some static rtlights with the properties you want in the same way that csaddon does, just do it without the whole userinput thing. parsing can be a pain though.
this would allow you to edit both sets of lights from a single place. or you could just use csaddon.

[toneddu2000]

[toneddu2000]

[toneddu2000]

[toneddu2000]

[Spike]

if you want to provide useful crash reports, reproduce the crash with a debug build and paste the first few lines of the stack trace that it spits out when it crashes (just make sure that its the current build at the time, or do the addr2line lookups yourself).

'no lights detected in map' was added to work around various TF maps becoming pitch black when the lighting tool stripped light entities.
it does not in fact disable rtlights (there arn't any loaded anyway), but merely sets r_shadow_realtime_world_lightmaps back to 1 until the next map change, thereby preventing the blackness without preventing mods from creating lights (either dynamic ones, or editing them with csaddon, or something more advanced).

regarding your $lightmaps on surfaces that don't have lightmap info... yeah, don't do that. it doesn't make sense.

[Spike]

[toneddu2000]

[toneddu2000]

[Spike]

those stack traces are not from my builds. I don't know what changes you've made.
my tools don't know what changes you've made either.
thus that stack trace is completely useless to me.
you would need to figure out the addresses yourself.

here's a link to debug builds that I can actually get line number info from: http://triptohell.info/moodles/win32/debug/fteglqw.exe

update your csaddon, it got a couple of extra fields (like rotating cubemapped 'static' lights).
you really shouldn't be using FULLDYNAMIC on any entity that your light/q3map2 tool will generate lightmaps for, or that the engine will autogenerate rtlights for. its's just wasteful. also, gamecode should try to avoid having hacks for the targetname, because hacks are bad.
I've heard people complain that -keeplights is broken in q3map2. I don't know the details nor version, just that someone I normally trust claims that it still stripped their lights.
use .style to get a FULLDYNAMIC rtlight to auto-animate according to a lightstyle.

[toneddu2000]