[FTE]Directional dynamic light implementation

[toneddu2000]

Hi guys! It's been quite a while that I'm struggling with the same question: would it be too hard to implement directional dynamic lights (aka sun light) in FTE with openGL? I read some papers and that explains that it wouldn't be a super hard task but the problem is..FTE code it's too complex. I don't even know where to start. I'd like to "simply" add a static directional light (even with hard coded inclination would be ok, not ideal, but ok) in openGL that works at least in client (read only-csqc games: yes in FTE you can create a only-csqc game!) but I cannot understand where FTE starts to draw lights. I tried gl/gllight.c and took a quick look at R_RenderDlights(), but I didn't find anything useful.

Anyone could please guide me in the right direction?

Thanks in advance guys!!

[Spike]

'directional' light is just such a vague term.
there are 3 'basic' types of rtlight.
1) omni-lights that cast light in every direction from a central spot (something like a cubemap).
2) spot-lights that cast light in a single direction from a 'central' spot (pretty much just a single face of the aforementioned cubemap).
3) parallel lights that have no central spot, but instead project from one side of its logical cuboid to the other.

(there's actually many different ways an engine could implement the above. deferred, forward, forward+, etc. then there's different ways to do shadows. stencil, cubemaps, dual-paraboloid, etc... but I'm ignoring that stuff for now, and focusing on just FTE's forward rendering.)

What you're asking for is the third type, but FTE only supports the first two right now.
parallel lights are interesting in that they're just weird. Logically, they're just a really (infinitely) far away omni light. except that this means that you might as well treat them like a spot light without the spot filter. and their infinite-distance nature means that they should use an orthographic projection matrix instead of the frustum-based projection matrix that a spot light or omniface would use.
orthographic matricies have no single point of origin, which makes pvs checks really messy (you'd have to scan for all leafs that contain an entire bounded plane), or just disable pvs checks... *shrug*.
so yeah, if you take the spot-light code, change the shadow generation to use an ortho matrix (the Matrix4x4_CM_Projection_Far line in Sh_GenShadowMap), change the projection glsl to use an ortho matrix (this is messy, the matrix is passed via a simple vec4 and transformed weirdly in the glsl for the benefit of omni lights), somehow define a non-axial cuboid for your light's volume that encompasses all visible geometry for your light to project over (or just use the worldmodel's bounds, if you're lazy), and disable all pvs checks when generating the shadows (beware of lights inside walls!), then you should have something close to what you're after.
getting it to work without breaking spotlights in the process is a bit more of a challenge... bonus points if you can
note that many implementations of such lights actually define multiple cuboids, with multiple shadowmaps, as a way to avoid depth precision issues on large maps. terrain systems might need it, but if your map is small or you're willing to fade the effects of the sun's shadows with distance then its probably overkill. Note how this stuff is all kinda special-casey, which is why I never sought to address this stuff - the idea of lights emitting from an entire plane that is actually inside a wall kinda put me off.

[toneddu2000]

Thanks Spike for the detailed reply. Instead of modifying spot light code, would it be possible to:
1. Removing light decay from omni light(I know it would be always an omni light, but at least there wouldn't be any attenuation from center of light)?
2. Using spot light with cubemaps with just one cube face as "hole" where to project light(again, lame solution, but..)?
3. There's the possibility to "lengthen" shadow computation with very far omni lights? Because, when I use a distant omni light (say [0,0, 1024]) with a big radius (like 8000), shadows didn't reach ground perfectly, they're like very low detailed. Once, I touched engine code to increase shadowmap to 8192 px but it was idiotic, I admit.

If these 3 options are (probably) lame or not feasible, could you tell me where's the portion of code that manages spot light?

On a side note, in CSQC, which is the method to use spotlight? Is it perhaps the 5th argument of dynamiclight_add() func? Where it says "optional string cubemapname"? So, filling that with cubemap, will it transform omni light in spot light? And, which would be the "orientation" of light cubemaps?

Just to know, are you planning to add parallel light support in future versions of FTE or it's not one of your prerogatives? Because if not, I'll try to tinker with spotlights code on my own but I don't guarantee any results!

Thanks again

[Spike]

float light = dynamiclight_add(...);
dynamiclight_set(light, LFIELD_ANGLES, self.v_angle);
dynamiclight_set(light, LFIELD_FOV, 90.0);
will add a spotlight with a 90-degree cone. larger values will be distorted, 180+ will bug out completely, much like the fov cvar.

that's the theory anyway. they don't get tested enough - they might be completely bugged right now... have fun...

[toneddu2000]

[toneddu2000]

[Spike]

LSHADER_ORTHO was me having a go at ortho lights, but I never actually got it working properly.

Matrix4x4_CM_OrthographicD3D is NOT what you want. gl uses matricies that span from -1 to 1 for depth values. d3d uses 0 to 1. mixing them badly will result in some screwed shadow maps.
I don't remember if the y coord is negated or not - remember that 0 in gl is the bottom of the screen rather than the top, and thus t=0 is the BOTTOM of the texture too, so if your code assumes that t=0 is the top of the texture then you'll need to use t=1-t to fix that.

the point about ortho matricies is that the near plane can trivially be negative. you might want to put the near plane at 0 though, thereby ensuring the light itself is positioned on the near plane itself. however, note that this then means that your light's origin will probably be outside the map, which brings me to the next issue.
pvs - if you want to calculate the pvs properly, you'll need to find all the leafs that the near clip plane passes through and merge the pvs of those leafs. however, most of those will be inside a solid wall which would stop shadows from being generated in that entire area, so you might want to just be lazy and use the entire ortho frustum, or just not bother with the pvs at all.
one fancy option might be to come up with a way to flatten all the leafs to find the nearest ones, but that stuff sounds much more complicated and expensive, I'm not entirely sure on the maths needed, should be okay for a static light though, I guess.

note that not only do the shadows have to be generated with a suitable ortho matrix, but also your glsl needs to sample from the correct part of the cubemap - which means incorporating the same ortho values into your glsl.
essentially, your shadowmap needs to contain depth values generated with an ortho matrix, and your shadowmap needs to be sampled as though it were projected across the same ortho frustum's front plane. so you calculate the world coords in your vertex shader and then project those through the inverse of your ortho matrix combined with the light's modelview matrix, or something. calc the distance between that light's near plane and the vertex, shove that into a varying, and compare that to the sampled values inside your fragment shader to see if its in shadow or not. you'll want to grab a few samples (eg: textureGather) in order to smooth things out a bit.

that's all really badly explained, but it might give you a few pointers. (void*)0xdeadbeef. there, have another pointer.

[toneddu2000]

[toneddu2000]

[toneddu2000]

I for implementing dynamic shadows on FTE. Let's see if someone replies. I don't know if offer price it's too low..

[Vic]

Hi toneddu2000,

you might want to look into some of my work on ortho lights (which also include lights from sky brushes) and parallel split shadow maps over here:

https://github.com/Qfusion/qfusion/commits/rtlights2

https://github.com/Qfusion/glsl/commits/rtlights2

The code is 90% done and tested, only needs partial rewrite here and there, especially the part that constructs the skylight volumes. The most obviously missing feature is blending between cascades. That I'm going to implement some time later.

Cheers!

[toneddu2000]

Thanks a lot Vic, that really means a lot to me. Honestly, I must say, I was thinking to abandon FTE because of the lack of dynamic parallel lights, but I'll definately look at your code.
I'll let you know if I succeed.

Thanks again

[toneddu2000]

Just some heads up: could you please tell which files should I look into it?

[Vic]

[toneddu2000]

can you please tell me how to go back and forth through commits in GitHub...I'm pretty noob about it..