Now that I'm part of the Ogre team, I get to work on Ogre even when its not SoC season
During the last SoC project, there were some ideas that didn't make the cut mainly because of time constraints. Now that the main batch of planned improvements are in, I can continue working and adding flexibility-oriented features to Ogre to make even more modern/advanced rendering techniques elegantly possible. So, here are my two proposals :
Compositor content_type in textures and content_type indexing
In some techniques, individual objects require the 'full scene preprocessing' textures, for example inferred lighting. This means that a new content_type will be introduced (current ones are regular and shadow) for referencing compositor textures.
Code: Select all
material InferredLighting/SomeObject
{
technique
{
scheme InferredMaterial
pass
{
...
texture
{
content_type compositor
}
}
}
}
Code: Select all
compositor InferredLighting/MaterialPass
{
texture_ref LBufferOutput InferredLighting/LBuffer mrt_output
target_output
{
material_scheme InferredMaterial
render_scene
{
input 0 LBufferOutput 0
}
}
}
Code: Select all
texture
{
content_type compositor
content_index 0
}
Code: Select all
texture
{
content_type compositor 0
}
- Which textures get overwritten during the render_quad phase of compositors? The first ones, according to the order of inputs. This is completely implicit and results in the quad-casting materials looking weird (empty texture units etc).
- Which shadow textures get passed when using content_type shadow? The first ones, by order of appearance in the material definition. You cannot explicitly request the 2nd shadow texture.
For backwards compatibility, we can assign running content indices where the directive is not present, and thus old materials will behave the same.
There is an option to have the content_type references named, but I think this is a slightly bigger change that is not necessary. Indexing should be flexible enough, and the explicitness of them will make scripts more readable.
material_scheme at composition pass scope and late material resolving
The motive behind this is to allow different render_scene directives to render using different material schemes. For example, a deferred shader currently needs many target passes just to bypass this issue, causing a performance hit.
In my opinion, the "material_scheme" directive belongs in the pass scope, and not in the target scope. The directive is usually applied to render_scene passes, and if someone puts render_scene and render_quad directives in the same target operation, do they expect that the quad's material will be affected by the material scheme? I don't think so. The downsides of the solution are that they break backwards compatibility and might cause script duplication (if you really want the same custom scheme for multiple passes). A possibility to solve these downsides is to allow the directive at both scopes, but I really don't like that option. I think that material_scheme really belongs in the pass scope.
This isn't currently possible either. Technique resolution (which is where missing techniques are handled) happens during updateRenderQueue, which means that you cannot resolve techniques based on the scheme that will be active during their render queue. The way to solve this IMO is to introduce a 'late technique resolving' option. When triggered (in the SceneManager probably), it will cause the scene manager to resolve the technique from the renderable again at render time, and use that instead of the technique that was linked to the Renderable in updateRenderQueue. This will cause mid-rendering scheme changes to affect rendering. The render_scene composition pass will automatically enable this flag when it has a manual scheme, making things work as expected in the script.
Both of these changes aren't big / hard changes code wise, but should be discussed before implemented, as they have implications. What do you guys think?