Page 1 of 2

[Implemented] Next compositor improvements

Posted: Sat Nov 07, 2009 9:41 am
by Noman
Hi all,

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
       }
     }
  }
}
I'm looking to have this change be as 'quiet' as possible, without changing too many core types. I think it should still be pretty tightly coupled with the compositor framework, so this will only be accessible from objects rendered within a compositor render_scene target pass. The 'input' directive will now have meaning during a render_scene pass :

Code: Select all

compositor InferredLighting/MaterialPass
{
  texture_ref LBufferOutput InferredLighting/LBuffer mrt_output
  
  target_output
  {
    material_scheme InferredMaterial
    render_scene
    {
      input 0 LBufferOutput 0
    }
  }
}
How will multiple textures be handled? Using a new 'content_type' directive. Whenever referencing a special content type (compositor or shadow) there will also be an optional index parameter that will tell you which of the special textures to use. This can be done either as separate parameter :

Code: Select all

texture
       {
          content_type compositor
          content_index 0
       }
Or as an additional parameter to the content_type directive :

Code: Select all

texture
       {
          content_type compositor 0
       }
I believe this content type and extra index also solve some 'implicit magic' that ogre currently use :
- 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?

Re: Proposal : Next compositor improvements

Posted: Sat Nov 07, 2009 1:41 pm
by madmarx
Please, please, please, could you put a drawing or a pseudo code of what kind of successive pass / buffer render / you want to acheive. That is a language that I can understand. Not compositor. And then let's see how it can be specified compositor or any script that could handle it.

Example of what I mean + a note about my own work :
I needed something that allowed me to describe a material that allow to do :
pass 1 => rtt to texture tex1
pass 2 => rtt to texture tex2
pass 3 (using texture tex1 and tex2) => to texture tex3
pass 4 (using texture tex3) => to color buffer
And this would be done for each entity (not renderable in my case) using this material.
As a consequence, I asked if "user_parameters" could be added to materials. And of course the topic was hijacked by people wanting to put physics in it. And of course the moderators told "we don't want ogre materials user params for physics!". lol. Thank god, Praetor wrote the new scripting system.
So I rolled my own system which allows me to specify a target texture for each pass if I want. I just create dynamically materials based on the informations I have put in the first big material. And I render either during scene update, or when needed. Then I authorized to group the rendering of renderables for the pass1 / pass2 etc... to reduce the intermediate render costs. In the end I just need to write a material script and I am ready to work. Of course this is much simpler now for me to export from rendermonkey.

If you can explain it like that, I might be able to understand what you are describing :D . At least for the first part, because the second part (scheme in pass) is much more clear for me.

Re: Proposal : Next compositor improvements

Posted: Sat Nov 07, 2009 3:35 pm
by Noman
What you are talking about is the other half of the compositor<->material bridge - being able to specify RTT passes in normal materials.
This is a bigger step than the one I am proposing, and while being very useful, is not what I'm trying to achieve with these steps.

Inferred shading is a good example of what one might want to do with this system.
The rendering pipeline that we want to execute is

Code: Select all

- Render normal + depth of entire scene to an RTT
- Create edge detection / other intermediate textures from the normal/depth texture (also rendering to texture) 
- For each object : render to color buffer using the RTTs from the previous stages as input.
The first part that I talked about makes the "using the RTTs from the previous stages as input" part possible and easy.

This is not instead of something like you suggested, but it is a much smaller change in Ogre and opens up some nice opportunities, so I would like to pursuit it.

Re: Proposal : Next compositor improvements

Posted: Sat Nov 07, 2009 11:00 pm
by madmarx
Ok thanks I understand better.

At first glance the new content type is ok. But I think there is easier. The indexing makes me wonder things for shadows :
You cannot explicitly request the 2nd shadow texture.
But we need it for pssm ? Or did I miss something?

Code: Select all

material shadowed_base
{
	technique 1
	{
		pass
		{
			vertex_program_ref exampleVP 
			{
			}
			fragment_program_ref exampleFP
			{
			}
			texture_unit 0
			{
				tex_coord_set 0
			}
			texture_unit 1
			{
				content_type shadow
			}
			texture_unit 2
			{
				content_type shadow
			}
			texture_unit 3
			{
				content_type shadow
			}
		}
	}
}
Now another question :
if I use 2 different compositors simultaneously, then I got to count exactly their order and make a sum in order to find the index? Or is the count local to the compositor running?

A suggestion :
I think you could use texture_alias instead of "a new content_type + index".
in the compositor just say which texture_alias(es) you want to overwrite temporarly (only for the time of the render_scene) and everything is fine.

the texture_alias system is much more powerfull, simplier to read and it will even be possible to ping-pong between compositor and passes without difficulties.

With textures alias I think you can do:

Code: Select all

- Render normal + depth of entire scene to an RTT
- Create edge detection / other intermediate textures from the normal/depth texture (also rendering to texture) 
- For each object : RTT using the RTTs from the previous stages as input. "texture_alias_overwrite name_of_alias sourcetexture".
- Use the previous RTT to do a RTT of a gaussian blur on the whole scene
- For each object : render to color buffer using all the RTTs from the previous stages as input. "texture_alias_overwrite name_of_alias2 
sourcetexture2". 
The downside is that it forces the user to define/rename some texture_alias. So it may not be a pretty solution either.

Re: Proposal : Next compositor improvements

Posted: Sun Nov 08, 2009 9:46 am
by Noman
At first glance the new content type is ok. But I think there is easier. The indexing makes me wonder things for shadows :

You cannot explicitly request the 2nd shadow texture.


But we need it for pssm ? Or did I miss something?
We can access the 2nd shadow texture if we want, but it forces us to access the first as well.
What if you ONLY want the 2nd texture?
(I can't currently think of a proper problem that needs this as a solution, but I'm not too knowledgeable about shadows in general).
if I use 2 different compositors simultaneously, then I got to count exactly their order and make a sum in order to find the index? Or is the count local to the compositor running?
The count is local to the inputs of the composition target pass. If the compositor is

Code: Select all

render_XXXX (could be quad, scene or even custom)
{
    input 0 SomeTex
    input 1 SomeOtherTex
}
then the count uses the same indices as the inputs, and its only relevant during that composition pass scope. It is a bit limiting, but I think that its just strong enough to solve all the problems that need this kind of addressing. If you need input from RTTS from two different compositors RTT, use texture_ref sharing in the compositor that triggers the composition pass.

One of the targets of this design is to solve the problem while introducing as few terms as possible to ogre's scripting system (or ogre in general) and staying true to the current design of ogre. Except for the compositor content_type (and the index) I don't add any new terminology.
Also, the texture_alias idea is nice and might be a bit more flexible, but I don't like implicit stringy dependencies. A typo wouldn't result in any runtime error, just in things not appearing right.

Re: Proposal : Next compositor improvements

Posted: Sun Nov 08, 2009 10:30 am
by madmarx
thanks for the explanation.

Yes you don't introduce many things, but that forces the user to create a 'double binding' : I mean you have to change the compositor (fine) + the material with informations (less fine). I also think that if you don't want the compositor to always run, you can't draw the pass. While if there is a default texture, you still can (think to environment maps for example). And you can detects typos thanks to the default texture.

The typo thing could also be said for inheriting materials.
materialbase -> 1 technique -> 1 pass -> 1 texture_unit called 'hello'
materialinherited -> 1 technique -> 1 pass -> 1 texture_unit called 'helllo'
you end up with 2 texture_unit instead of one. But I don't see much people complain about that on the forums. As a consequence, I think that the typo is not such a real problem (well of course, with the "set $" there is less possibilities to make mistakes :mrgreen: ).

Your solution is ok. But I would even prefer to change things only in compositor, not in materials. Otherwise, materials exporters needs to be rewrote etc... please be careful about that, it has big consequences.

Re: Proposal : Next compositor improvements

Posted: Mon Nov 09, 2009 1:14 pm
by sinbad
Good thoughts overall. I'd like to suggest a couple of variations though.

Compositor content_type in textures: The double-matching approach is similar to the double-matching done with some other things in Ogre such as the per-renderable custom parameters. However it does require an additional level of indirection which makes it harder to figure out, and also I wonder how this would behave if you had a chain of compositors where more than one wanted to export their results - you could get clashes which would require one or other of the compositor definitions to be changed.

Instead, I'm wondering whether this can't be resolved with a simpler named approach, which would not require any changes to the compositor. Essentially the compositor doesn't need to know about the material, but the material needs to know about the compositor, so why not make it a one-way link and make it an 'absolute path'

Code: Select all

content_type compositor <compositor_name> <compositor_texture_definition_name> [mrt_index]
This reference works relative to the current Viewport, and in fact doesn't require any specific hooking up in the compositor system, so actually it doesn't have to be used during the render_scene pass (although that's most likely where it will be used). I like that better because you can pull textures out of the compositors now (I do it for debugging) just via material definitions and this is just automates that with no additional restrictions or assumptions. It's just a bit "lighter" and unambiguous I think.

material_scheme at composition pass scope: Yes, I agree that this is more useful. But I think it's ok to allow them at both scopes for backwards compatibility, and just interpret scheme at target scope to mean that it applies to all passes. This is what was done when attributes were moved around the material system in our history too. About the implementation, late-binding could work, but please see my notes on "Re-using render queues" below- it could be that a common approach could address both of these issues.

A couple of other related thoughts..
Disabling shadow rendering in a compositor pass - I don't think that we can currently disable shadow rendering in a render_scene pass, can we? We probably want to be able to do that so that other render_scene operations can be done without shadow textures being updated when we don't need them to be.

Re-using render queues - sometimes when you're rendering more than once, you're rendering the same scene from the same perspective but into different targets. If it's in the same target it's just a separate Pass, so the render queue is automatically re-used. But when doing deferred lighting, you're rendering into different targets, one for the shadow render, and one for the final render. Ideally you don't want to go through findVisibleObjects twice for that because the results are the same. It would be nice to be able to 'stash' and re-use render queues between targets I think; although there are some complications because the render queues already include Pass information so the material schemes etc have already been resolved - this is exactly the same as your issue with material_scheme at pass level. Your late-binding option would help, but there may be a need for a higher-level review of render queues here; whether we should have the queues at two levels - the Renderable queue, with no technique or pass resolved, and then a fully resolved version including pass information. The downside is that sorting can only be done (state or transparency) once we have resolved which passes are needed, and if for whatever reason the results are the same, we really don't want to do the pass generation and sorting twice. So maybe we need some kind of 'scheme hash', or similar, which represents a unique identifier for how the list of renderables is turned into a (sorted) list of pass/renderable combinations, then we'd know whether we can re-use a queue with its full pass/renderable sorted lists, or whether we need to generate a new set from just the Renderables, resolving the passes again. So we could potentially re-use the raw renderable list and generate a new sorted pass/renderable list, or re-use the whole thing if the "scheme hash" was the same (or neither if we need to find visibles from scratch again). More investigation is needed on this because ideally we don't want to break too many interfaces (this will all be 1.8 or above) but we could potentially open up a few new avenues of both flexibility and optimisation in this area.

Re: Proposal : Next compositor improvements

Posted: Mon Nov 09, 2009 2:46 pm
by tuan kuranes
Sound all very useful to me. Great design, Noman !
I do vote for the absolute path naming 'content_type' (sinbad's suggestion).
could potentially open up a few new avenues of both flexibility and optimisation in this area.
Renderqueue reuse would be nice indeed, and could indeed lead to more "data oriented" algorithms, more multihread and cache aware. Could even make the render scene manager more readable. If user side, you can tweak in the render queue resuse/hashs, user would gain more control. Some further optimisation like "bucket sorting" for instance, reusable by multiple cameras could be made by user.

Re: Proposal : Next compositor improvements

Posted: Mon Nov 09, 2009 4:35 pm
by Noman
@content_type syntax
Direct naming could be simpler, it can simplify stuff (like the RTT debugging in the compositor sample). madmarx's comments about having to change materials is a valid one, but I don't think that the exporter changes are that big an issue. You could solve this with inheritance and stuff like that.
It does involve in adding a few more fields to TextureUnitState, but other than that its fairly simple and straightforward.

@material_scheme scope
Yea, backwards compatibility is nice. I just don't like the code duplication that this will cause, but this could be phased out over time if we wanted.

@Disabling shadow techniques
This is possible today, but is currently at the target pass scope, just like material_scheme. Promoting it to the Compositon pass scope makes the same sense as material_scheme.

@Re-using render queues.
I've thought about this during the SoC project, but ultimately led me to thinking about very big changes in Ogre, like you said. Specifically, I thought about the fact that SceneManager needs to be split up into smaller chunks! I saw the RenderQueue as a good handoff point between the class that does findVisibleObjects and all that and the (new) class that actually sends the rendering commands to the RenderSystem. However, I didn't think this through 100% yet as it is SUCH a major change.
While I do agree that it is the true solution to the problem, promoting material_scheme to CompositionPass scope is meaningless without late binding, so I think it should go in if we decide that we are going after this change at all... Perhaps as a temporary solution, but it needs to be there until the SceneManager redesign - I don't think that the bigger change is 'hackable' so to speak...

Re: Proposal : Next compositor improvements

Posted: Tue Nov 10, 2009 6:28 pm
by sinbad
Yes, you're right. The other thing redesigning the queues could open up is multithreading of sub-scene visibility detection, which slots right into the Tindalos (Ogre 2.0) feature area. I can see lots of potential for tackling a whole bunch of things at once. But this will take some time :)

Re: Proposal : Next compositor improvements

Posted: Thu Nov 12, 2009 3:40 pm
by Noman
Right, so I think I'll include them in my list.

So, I think I'll stay pretty close to my original plan in this phase :
  • The compositor content_type will be introduced, with sinbad's syntax suggestion being adopted
  • Late material binding will be introduced (as a SceneManager flag), will remain there at least until the SceneManager / RenderQueue redesign
  • Material scheme will be added to the pass scope as well, staying in target scope for backwards compatibility. Late material binding will be automatically enabled when switching schemes at pass scope.
  • Shadow casting at pass scope? Not sure how important this one is, again, only relevant if there are multiple render_scene directives. But thats what we're addressing :)
Besides the script/code duplication between the target and pass scopes, I think this is very elegant. That can be solved later by deprecation, should we choose to fully adopt the pass-scope option (which I think, is more correct in terms of control).

I'll probably get working on this in a few days, I don't expect it to take much time. The material binding / scheme will be used in the deferred shading demo (should give a performance boost!), and I might add a playpen test for the content_type until I roll out a demo that actually uses it. (Might be cool to change the deferred shading demo to a comparison between forward, inferred and deferred shading. That will be awesome.)

Re: Proposal : Next compositor improvements

Posted: Thu Nov 12, 2009 6:30 pm
by sinbad
Noman wrote:Might be cool to change the deferred shading demo to a comparison between forward, inferred and deferred shading. That will be awesome.
Hell yes. However I think a simpler light pre-pass renderer (or deferred shadowing if you like) would be my preference as a first step over inferred shading. It's a bit simpler and more proven :)

Re: Proposal : Next compositor improvements

Posted: Fri Nov 20, 2009 10:39 am
by lf3thn4d
Awesomeness! Noman, are you working on this already? This will be great since I'm thinking about switching my rendering technique to a light pre pass technique. My game was having difficulties doing indoor environment with lights everywhere. This would also help plenty for other screen-space features for free since it generates a depth buffer too. :)

If you're working on this already, it'll be cool if you can check out my patch on auto updating camera to RT viewport when the main viewport changes camera:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=53330

Re: Proposal : Next compositor improvements

Posted: Fri Nov 20, 2009 1:26 pm
by Noman
I'm working on it :) Will get to your patch when I'm done with it.

As for my progress - there is a problem with this :
This reference works relative to the current Viewport, and in fact doesn't require any specific hooking up in the compositor system, so actually it doesn't have to be used during the render_scene pass (although that's most likely where it will be used). I like that better because you can pull textures out of the compositors now (I do it for debugging) just via material definitions and this is just automates that with no additional restrictions or assumptions. It's just a bit "lighter" and unambiguous I think.
The problem is that during quite a bit of the compositor pipeline, the current viewport is NOT the one that has a compositor chain attached to it. For example, whenever you are rendering to an RTT as part of a compositor chain.
So, a 'central repository' of some sort will have to be introduced. I'm thinking that CompositorManager will have an 'active compositor chain' member that the chains will update when they start (and finish), allowing us to access the 'current in use compositor' from pretty much anywhere. Its either that or a similar SceneManager-hosted variable, which might be a better idea for threading purposes.

Re: Proposal : Next compositor improvements

Posted: Fri Nov 20, 2009 5:43 pm
by Noman
Committed compositor content_type to trunk

This version is a bit crippled because of the limitation stated in the last post. However, when the active viewport is the one being targeted everything works smoothly.
Another minor issue is a code redundancy one : MaterialSerializer::parseContentType receives a String with the contents of the line. The input of this line might be more complex now, because we might have names of compositors that include spaces, needing support for something like

Code: Select all

content_type compositor "My Compositor" "My Texture" 2
.

Currently, the script serializers can tokenize this correctly (split into four parts etc) but I don't have access to that functionality because of the scope that I'm operating in. Is there a function in Ogre somewhere that splits a string according to the space / quotes convention? If not, I'll write one and put it in StringUtil.

I also updated the Compositor demo to use this functionality to bring back the texture debug view, so if you get trunk you can see this in action right away.

Next up will be fixing the active viewport limitation / issue and the script thing, and then I'll move on to the pass-scoped material scheme and late binding.

Re: Proposal : Next compositor improvements

Posted: Fri Nov 20, 2009 7:13 pm
by lf3thn4d
Nice! :)
Noman wrote:As for my progress - there is a problem with this :
This reference works relative to the current Viewport, and in fact doesn't require any specific hooking up in the compositor system, so actually it doesn't have to be used during the render_scene pass (although that's most likely where it will be used). I like that better because you can pull textures out of the compositors now (I do it for debugging) just via material definitions and this is just automates that with no additional restrictions or assumptions. It's just a bit "lighter" and unambiguous I think.
The problem is that during quite a bit of the compositor pipeline, the current viewport is NOT the one that has a compositor chain attached to it. For example, whenever you are rendering to an RTT as part of a compositor chain.
So, a 'central repository' of some sort will have to be introduced. I'm thinking that CompositorManager will have an 'active compositor chain' member that the chains will update when they start (and finish), allowing us to access the 'current in use compositor' from pretty much anywhere. Its either that or a similar SceneManager-hosted variable, which might be a better idea for threading purposes.
Yeah, viewport isn't a good scope to this. It's better to use the active compositor chain like you suggest. Having scene manager hosted variable isn't exactly a good idea i think. Considering that compositor chain has a one to one relationship with viewport, it'll just be an extra indirection to get the compositor chain; which is unnecessary. Unless this extra hosted variable (presumably the actual final scene rendering viewport) can be used for other unknown features in the future, I see this as unnecessary indirection.

Re: Proposal : Next compositor improvements

Posted: Wed Nov 25, 2009 5:12 pm
by Noman
My problem with using a 'global flag' is nested renders :
Lets say you render a certain pipeline and use the _pause/_resume frame capability in the middle, and render something to a texture which also uses a compositor. If the 'active compositor chain' is kept at CompositorManager scope, it would get overwritten...
I still like the SceneManager scope the best - that way it can easily take care of problems like these internally, and it makes sense, in my opinion.

And another question : there's something I don't get about script parsing. Do we still have two options to do it in the trunk? I currently see the parsing happening in two places : MaterialSerializer and ScriptTranslator. Are both of them still in use?

Re: Proposal : Next compositor improvements

Posted: Wed Nov 25, 2009 5:33 pm
by sinbad
Noman wrote:

Code: Select all

content_type compositor "My Compositor" "My Texture" 2
.

Currently, the script serializers can tokenize this correctly (split into four parts etc) but I don't have access to that functionality because of the scope that I'm operating in. Is there a function in Ogre somewhere that splits a string according to the space / quotes convention? If not, I'll write one and put it in StringUtil.
Sorry I missed this post before.

There is a StringUtil::split but it won't do what you want, I guess you're looking for a StringUtil::tokenise. However, another option is for the script compiler to split the parameters and to place them in a StringVector, or to otherwise find a way to store the post-parsed values relatively generically. We'll need it later probably anyway since I have other uses for content_type in future.
Noman wrote:Lets say you render a certain pipeline and use the _pause/_resume frame capability in the middle, and render something to a texture which also uses a compositor. If the 'active compositor chain' is kept at CompositorManager scope, it would get overwritten...
I still like the SceneManager scope the best - that way it can easily take care of problems like these internally, and it makes sense, in my opinion.
Doesn't SceneManager have the same problem? If, as is often the case, the same SceneManager instance is used to render most render targets, it will suffer from the same issue if the current viewport is a member variable in a re-entrant render. We already have this problem in SceneManager::renderScene and doing shadow textures in fact, and we resolve it by storing & restoring the current camera / viewport settings, but obviously this isn't possible in a generic interrupted sense.

I think what we're actually talking about here is a 'stack' of state, where each time SceneManager::renderScene is called the current state like camera and viewport are pushed onto the top of a stack, and popped off again at the end of the method. Accessing the 'current' just gets the top of the stack, but you could also access the 'ultimate' final target by reading the bottom of the stack. This would clean up the regular shadow rendering state hacks as well as managing your case, I think.

Re: Proposal : Next compositor improvements

Posted: Wed Nov 25, 2009 6:23 pm
by Noman
Haha I named it tokenise as well :) (is it with an S or a Z ?) Although I didn't test it yet cause the code doesn't currently use MaterialSerializer for deserializing materials... Will do some offline testing before I commit it to be sure that its ok.

As for the render state stack management - essentially, that is what happens today. pauseRendering returns you a RenderContext object which you must pass back to the scene manager when calling resumeRendering. This is essentially a stack based flow, except that there isnt a central stack keeper (this would be the scene manager in the solution that you proposed).
However, the current design of things is not stack based, which means we will have to change quite a bit to make it work like this. For example, a compositor chain renders its child viewports during preViewportUpdate, meaning its before the viewport even started doing stuff.

If the SceneManager is the parent scope, setting the 'active chain' in the beginning would cause it to be there the whole time. The pointer could be stored in the RenderContext, allowing it to be restored in a stack-like fashion when resumeRendering is called.

So, to sum up my proposal :
  • SceneManager exposes set/get ActiveCompositorChain
  • A pointer to CompositorChain is stored in the RenderContext and used accordingly (pause/resume rendering calls)
  • CompositorChain sets this value in preViewportUpdate and clears it in postViewportUpdate
I think this isn't very hacky, doesn't require big changes and solves our problems pretty well.

Re: Proposal : Next compositor improvements

Posted: Thu Nov 26, 2009 6:12 pm
by sinbad
Ok, my only concern with that then is that, as I understand it, the active compositor is set and restored at different points to the rest of the render context, so the context could get confused if we use the same stack for both. Ie does the compositor chain push a new entry on the stack, or does the render? Because inside the render you can't necessarily tell. So I think they need to be different stacks.

If it is best to do them separately then actually you only have to worry about the chain context for this piece of work since we'd be saying that the active chain and the viewport/camera stack for re-entrant renders are orthogonal.

If you need a stack for the chain status, then I think it should probably be called pushActiveCompositorChain and popActiveCompositorChain so it's clear what's going on. I'm assuming the only time you'd actually nest chain updates is when you have cross-dependencies between targets which both have chains? Or is that needed at all?

Re: Proposal : Next compositor improvements

Posted: Fri Nov 27, 2009 12:01 am
by Noman
Its much simpler than that, the way I see it.
There is no proper stack-like data structure anywhere in the code, the call stack (or the program's pipeline) will be the stack holder, which makes sense.

Currently, you can not have re-entrant chains (IE update a viewport with a chain attached to it) without render pausing / resuming. (There are renders that start within a compositor chain, but they are part of a chain - rather than being a viewport which has a chain attached to it). So, the chain that is the parent of these viewports will be the active one during the whole render.

UNLESS something (like a custom composition pass) interrupts the rendering using pauseRendering and starts something else, in which case the active compositor chain will be stored (by the caller of pauseRendering in the RenderContext object), allowing sub-renders to operate (and do whatever they want, even activate more sub-renders) cleanly without disturbing anything. When resumeRendering will be called (giving the RenderContext as the param) the active compositor chain will be restored, and all will be good.

Re: Proposal : Next compositor improvements

Posted: Fri Nov 27, 2009 12:16 pm
by sinbad
Ok gotcha - I wasn't sure whether you had re-entrant chains in mind too. In that case, sounds fine.

Re: Proposal : Next compositor improvements

Posted: Fri Nov 27, 2009 4:18 pm
by Noman
Revision 9355 contains the "active compositor chain" changes. It ended up being a small change, so I'm pretty happy with it.

Chain-scoped material schemes and late material binding coming up next, which should give us a nice performance boost in the deferred shading demo...

Re: Proposal : Next compositor improvements

Posted: Fri Nov 27, 2009 8:39 pm
by Noman
I implemented the late material binding & pass-scoped material scheme.
Patch is available here.

I didn't commit it yet because I'm not sure I did it in an elegant way, so I prefer to have it reviewed & tested before its committed in. It shouldn't change anything if the new flags aren't activated, but I'm not sure that I put the hooks in the correct / elegant places.

The patch also contains the modification to the Deferred Shading compositor that uses the new features. It now works fine and uses one less full screen texture.
I think I'll commit this in a few days if no design / implementation issues come up (if they do, raise them in this thread).

Have fun!

Re: Proposal : Next compositor improvements

Posted: Sat Nov 28, 2009 2:08 pm
by sinbad
Thanks, I have a bit of a patch review backlog (will try to clear some this weekend) but will try to look at it soon.