GoogleCodeExporter
commented
8 years ago The current agenda for this issue is as follows:
1) Take out all rendering code from the Material class into either its own
utility class or something more modular (interface perhaps?)
2) Allow user code to control how a material is rendered:
* Query the lighting mode (fixed, single pass, multi pass)
* Single call to setup GL/renderer state to render the material
- render state
- select shader based on light type (for define based multipass or glsl 1.0)
- world params -> uniforms
- mat params -> uniforms
- light params -> uniforms (single pass takes 1 light as argument, multipass takes light array)
- unset uniforms not set by material
* The method would set the Shader and RenderState on the Renderer, from that point on simply rendering the mesh is enough to finish the rendering operation.
* In addition, the code handling rendering from this point on can choose to project the point/spot light volume onto the camera and determine a scissor box (to reduce fillrate where the light has no influence)
3) Given the functionality available in #2, its possible to sort the render
bucket by light type + shader and avoid render state changes
* GeometryList becomes BatchList -> The Batch class contains sufficient information to render the batch, such as: Geometry, Light, and distance to camera (rest TBD)
* When rendering "LightMode MultiPass" material, a single batch is added per light on the geometry
* When rendering any other material (single pass, unshaded), a single batch is added per geometry, the light field is set to null
4) The current light list management system in spatial needs to be changed to
accommodate the changes
* A light list refresh requires per light granularity: light addition / removal / modify transform operation require re-propagation for that light down the scene graph. A light can only be associated with a single node (the one that contains the light in its local light list). This allows the light to notify its parent node of changes in its own transform to execute the light list refresh operation.
* For each spatial in the subtree under the light, a culling operation is performed to check if the light is contained in that spatial's bounding volume. If the light does not intersect the volume, then that node is not influenced by the light and therefore the subtree under that node must not contain the light in its world light list (it may have been contained there previously ..) . If an intersection is detected, then this operation is performed for each child of that node. Once the leaves are reached, the light is added to their world light list.
* Given the above requirements (#4) the common case is satisfied: many lights on root node, most of them static. Some lights may be updated per frame, in that case their updates are checked against the entire scene graph (re-propagation), the number of intersection checks is reduced to minimum.Original comment by ShadowIs...@gmail.com on 9 Jul 2012 at 4:10
Original issue reported on code.google.com by
ShadowIs...@gmail.comon 13 Jun 2012 at 9:06