Random notes for RM development

Target manager

  • Split handling into two functions, one that collects and pushes on a queue and one that takes one entry from queue and sets it up (using a parameterized context setup function)
  • Distinction of setup function based on SV name (dispatch handled by RM)

Order of SV contexts

  1. shader
  2. global
  3. sector
  4. predefined (such as obj2world tf)
  5. material
  6. render mesh
  7. mesh object
  8. light

Shader and light setup relation

Shaders and lights have a complicated relation: a shader (technique) can say how many lights it can support; but the shader itself may vary depending on the number of lights. To reduce general confusion the setup of shader and lights follow this order:

  1. Choose shader for a mesh (depending on material and such)
  2. Based on the number of lights the shader(s) support(s) the light selection for a particular mesh is done.
  3. With the shader + affecting lights known a shader ticket can be selected.

Note: shaders also could have the ability to support a different number of lights on different HW. However, this number may also vary based on the actual types of lights used etc... so supporting that level of flexibility would require some rather arcane measures. Thus it was decided that the shader exhibits one number of supportt lights and "promises" to always support them, with multiple passes in the shader if necessary.

Lighting

The render layers specify what shaders are used for lighting. Shaders specify the amount of lights they handle - they make a promise and have to do multiple passes, if necessary; likewise, any fallback needs to support this specified number as well. (It would be nice if there could be some flexibility wrt light numbers in shaders. One idea: if all variations are processed, the number of lights all techs would support are known. This gives a maximum number of lights a shader can handle. Then, for a given ticket, perhaps multiple passes could be set up automatically, based on what the tech really supports...)

Render layers should prolly have some sort of "lights to handle" and "max passes" options to allow some independence of the number of lights a shader supports.

Default RMs to provide

  • classic (static lighting + all software lighting) - this is intended for "visual compatibility" for those who desire that
  • lighting (static lighting + HW lighting) - use static lighting if available; should look as good as it can; fallback to SW lighting if needed
  • lighting+shadowmap
  • lighting+stencil

Random notes on cutting down shader variations

<res|laptop> no, lights is the product I mentioned
<res|laptop> since N and N+1 lights would need different variations
<res|laptop> and if it's just that one instructs the shader to use N lights, the other N+1 lights :P
<thebolt> ah, right.. 
<res|laptop> but maybe that's just stupid
<res|laptop> and the light count for the shading setup should just be pulled out of the "light count" SV as well