Shadowmaps

[VReaperV]

This issue is to keep track of necessary steps and progress for implementing shadowmaps in the tiled renderer.

Required:

• Support for generalized texture atlases. These atlases should be able to pack multiple different textures into them, as well as support all of the required texture wrap modes (emulated in shaders). Converting all textures to compressed formats and caching them might be beneficial here to reduce the required amount of atlases.
• Additional data in tiles to tell which shadowmaps affect any particular tile.
• Rendering of shadowmaps into arbitrary parts of the viewport.
• Sampling of shadowmaps based on the tile information.

Optional:

• Shadowmap priority calculation. Based on eg: distance from viewpos, area on screen, light priority, light volume/area etc. This can then be used to determine the size of each individual shadowmap.
• Caching shadowmaps: only render shadowmaps if something in their frustum changed or the frustum itself changed.
• Caching static geometry in shadowmaps: render static geometry once (and if the light sources moves or changes its direction; for constantly moving lights, eg projectiles, it might be better to skip this part entirely) and then copy it when something moves in the view of the light source, and draw only the objects that moved.

[slipher]

I suppose shadows are expected to be cast by dynamic lights only? Since the information isn't really there for lights baked into the map. It's possible to instruct q3map2 not to remove point light entities, but then everyone says you should be using light emitting shaders anyway.
I don't remember anything about the old shadow implementation, so I'm just asking as if it's starting from scratch.

[illwieckz]

I suppose shadows are expected to be cast by dynamic lights only?

IT would be a good start, yes.

Since the information isn't really there for lights baked into the map. It's possible to instruct q3map2 not to remove point light entities, but then everyone says you should be using light emitting shaders anyway.

Indeed light entities could be used when not removed, and surfaces using light emitting shaders too (would require to also parse those keywords), when the shader is properly shipped with the map (it was possible to not ship some shaders if the image had the same name as the shader and some special effects like image scrolling were not used).

I wonder if we can also average some lightgrid direction.

[VReaperV]

Yeah, some information would be required for any shadows. I'm assuming light emitting shaders essentially work as spotlights where everything between where the light source would be and the surface itself is ignored? (and light falloff not applying until getting to the surface of course)

[illwieckz]

I'm assuming light emitting shaders essentially work as spotlights

Basically, yes. In fact the map compiler spawns a kind of spotlight every given subdivision, and this subdivision can be configured, but considering it as a spotlight at first would be good enough (and we may not want to render so many shadows anyway).

spotlights where everything between where the light source would be and the surface itself is ignored?

I don't get this part of the sentence.

[VReaperV]

I don't get this part of the sentence.

I'm imagining something like this:

[DolceTriade]

Averaging the lightgrid is possible and that's what we did in the past. It's just not super accurate, but if the shadows look nice, it still looks nice :)

I don't think we have any information about light emitting shaders except the light grid, which is super lossy.

[illwieckz]

The light emitting shader works like this:

                           light cone
      \       /   \       /
       \     /     \     /
        \   /       \   /
         \ /         \ /
          *           * light
         / \         / \ back splash
     ________________________ light emitting shader
/////|//////////|///////////|/////// wall
     |          |           | subdivision

A light is spawn a bit in front of the surface having a light emitting shader, with a back splash.

The distance of the light to the surface, and the intensity of the backsplash is configurable independently to the main light intensity.

• q3map_lightImage <path>: sample the light color from this image,
• q3map_lightRGB <R> <G> <B>: explicit light color,
• q3map_surfacelight <N>: light intensity,
• q3map_lightSubdivide <N>: spawn one light per N game units,
• q3map_backSplash <percentage> <distance>: configure the backsplash (percentage of intensity and distance to surface).

More details here: http://q3map2.robotrenegade.com/docs/shader_manual/q3map-global-directives.html

[VReaperV]

Hmm, interesting. How is the light cone size calculated though? I'm not seeing any mention of that. At least some light source for such surfaces can probably be combined to avoid building more shadowmaps.

[illwieckz]

DolceTriade dixit:
I don't think we have any information about light emitting shaders except the light grid, which is super lossy.

I guess we can iterate every surface of the geometry, compute the position in space, pick the material name, lookup for the shader, parse it and see if there is some light emitting keywords in its body.

VReaperV dixit:
How is the light cone size calculated though?

I even don't know if it's a cone, but I guess it's somewhat biased into some direction if it needs a backlight.

[illwieckz]

I even don't know if it's a cone, but I guess it's somewhat biased into some direction if it needs a backlight.

It may also be an half-sphere.