[SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Threads related to Google Summer of Code
Locked
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Tue Aug 04, 2009 7:53 am

jacmoe wrote:Maybe you could use the assets from http://www.robg3d.com/downloads.html ?
It's got a cathedral..
I checked it out... Its a nice cathedral, but
A) Its in .MAX format. (Less of a problem, cuz i think that max->ogre is the most active export pipeline, so that probably will work out)
B) The textures are 43 MB after I compressed them all to .PNG. I don't want to add that kind of mass to the Ogre SDK...

Still prefer to solve the issues with the current cathedral...
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Tue Aug 04, 2009 3:50 pm

The cathedral's geometric problems aren't that bad. I'll just focus the scene inside the cathedral, where its pretty much alright.

Started building a more complicated scene, and started seeing problems.
There seems to be a depth-related problem, I suspect the way I re-build the depth buffer :

http://www.youtube.com/watch?v=XH7uM1bdIeM
(Colored pixels = pixels where the spotlight is closer than the geometry)

It seems that the error is related to the distance of the pixel from the center of the screen - pixels in the center are closer, and pixels in the border are further (this picture proves that the center pixels are the right ones). Shader debuggin time!

Other than that, the new scene is coming along nicely. Here is a none-debug screenshot from a good angle :
Image
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Tue Aug 04, 2009 4:24 pm

Looks like something is wrong with the projection matrix being uses for the "restoring". What matrix ends up being use there?
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Aug 05, 2009 6:11 am

Z problems solved, things are looking correct now.
I just wanted to share a little eye candy...
One of the advantages of using a model that you originally saw in an SSAO demo, is that it works really well with SSAO.
Since the new demo uses normal metric modes (1 unit = 1 meter) the original SSAO constants work wonderfully in this scene.

This is a shot without SSAO :
Image
And with (see the wall behind the ogre head, for example) :
Image
And the SSAO Buffer (not same session, so camera isnt in the exact same place) :
Image

This is starting to look alright :)
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Aug 05, 2009 7:06 am

Design time again!

I'm currently dealing with transparent objects. This is the flow I wanted :

1) When the GBuffer scheme handler inspects an objects (to auto-create the GBuffer writing pass) it also checks if a pass is transparent.
2) An additional technique will be created called "NoGBuffer" (or something similar) - all the passes that can't get written to the GBuffer get copied to this technique.
3) After rendering the lights, an additional render_scene directive will be dispatched with the NoGBuffer material scheme, so all transparent passes within the GBuffer render queue range will render themselves normally now.
4) After that, the post-GBuffer render queue range objects get rendered normally.

This is how the compositor would look :

Code: Select all

compositor DeferredShading/ShowLit
{
	technique
	{
		//Reference the main Gbuffer texture
		texture_ref mrt_output DeferredShading/GBuffer mrt_output
		
        target_output
        {
			input none
			
			pass clear
			{
				
			}
			
			// render skies and other pre-gbuffer objects
			pass render_scene
			{
				first_render_queue 1
				last_render_queue  9			
			}
			
			//Render the lights and their meshes
			pass render_custom DeferredLight
			{
				input 0 mrt_output 0
				input 1 mrt_output 1
			}		
			
			//Render the passes that did not get written to the GBuffer
			pass render_scene
			{
				material_scheme NoGBuffer
				first_render_queue 10
				last_render_queue 79
			}
			
			// Render the post-gbuffer objects
			pass render_scene
			{
				//This value is synchronized with the code
				first_render_queue 80
			}
			
		}
	}
}
Why did I choose this approach?
The alternative was to change the visibility mask or render queue of the transparent passes. The problem is, visibility masks and render queues are properties of MovableObjects and not passes. I need to potentially be able to split an object's rendering into two different parts. This is a pretty big change in ogre that I don't want to do. (And don't think is right)

Why can't I do this right now
The compositor script I wrote there is illegal. The problem? the "material_scheme" directive belongs in the target scope, and not in the pass scope. This means that I can't have different material schemes in different render_scene passes.

Why not split the passes into different target operations?
There can only be one target_output pass in a composition technique.

Solution
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.

[EDIT]
My solution 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.
I'm going to have to find a different solution, or change more stuff in Ogre. Ideas?

[EDIT2]
As a temporary solution, I am now rendering everything into an A8R8G8B8 buffer, allowing me to have multiple target passes before outputting the entire thing to a texture. This does introduce an additional full screen quad rendering, and costs another full-screen 32 bit texture, but I didn't have to change anything in ogre. Not happy with this, but I can't think of a better solution right now.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Aug 05, 2009 4:34 pm

Moving on to shadows, I think the work I did earlier is paying off. I managed to generate a shadow texture (didn't use it yet, so no screenies so far) mid-frame and keep on going. However, I encountered a problem that I'm pretty sure is related to depth buffer sharing.

When the deferred output compositor renders straight to the back buffer, the output looks good. Like this (Ignore the colors... debug view etc) :
Image

When the compositor renders to a texture (for example, because of the changes I made in the last post), the output looks like this :
Image

You can see that the problematic area is in the top left square of the screen. It is 512x512 pixels big, which is the exact size of the shadow texture according to the current config. And it looks a lot like the depth result from where the spotlight is rendering.
To prove that this is indeed the problem, I made an even more extreme test - I used the original (write directly to output) compositor, everything is good. The instant I switch SSAO on (and thus the deferred render is to an RT), I get the shadow artifact again.

So, it seems that ogre is sharing the depth buffer behind the scenes. Its alright if you render shadow textures the classic way (IE, all of them before the main scene render) but if you want to reuse the same texture for all spotlights, it won't work.
In order to solve this, I need to either
A) Rebuild the depth buffer after every shadow texture I render (boo!)
B) Stop sharing the depth buffer between the shadow texture RTTs and the normal RTTs.

I'll probably dive in and start reading documentation on when/how depth buffer sharing works, but some input would really help me here...
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Wed Aug 05, 2009 5:53 pm

Wait - NOW it started sharing the depth buffer?

Wait ... before you were rendering to the main window? I think that might be why it didn't share the depth buffer - I'm not sure if it shares the depth buffer between RTTs and the main window, or just RTTs in general. However, I believe the shadow map shouldn't have a shared depth buffer because it's a different size from the other stuff. Yeah, I'm pretty sure it definitely shouldn't be behaving like that.

I think it might have something to do with your "mid-scene" rendering of the shadow map. How does that work? Is it some sort of "call _renderScene() while already inside a _renderScene() call"? I always shoot for a single _renderScene() at a time, which is why I do all of my stuff manually.
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Praetor » Wed Aug 05, 2009 6:00 pm

Is there a way to "look ahead" and discover what shadow renders will be needed and render them all ahead of time? Or do you need shadow buffers "just in time" so you can reuse shadow textures?
0 x
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Wed Aug 05, 2009 6:10 pm

Praetor wrote:Or do you need shadow buffers "just in time" so you can reuse shadow textures?
That's the idea.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19263
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Wed Aug 05, 2009 6:57 pm

Re transparent objects: yes I agree the material_scheme belongs in the pass scope. Maybe it could just be supported in both, and that if it's in the target scope that just applies to all passes.

However, yes you'd probably be too late to resolve the scheme that way using the standard approaches. You can switch out the technique that's added to the list in a RenderQueue::RenderableListener but that's at findVisibleObjects time. However, when the queue is invoked, you can potentially do anything you like with what's been queued. RenderQueueInvocationSequence has an invoke() method for each group, which the default boils down to SceneManager::_renderQueueGroupObjects, but there's no reason why you couldn't change that; either by whipping down the group yourself invoking the render differently, or by replacing the content of the list (repointing the Techniques) then calling the general method.

Re depth buffer sharing, yes, here's what happens: when a depth buffer is requested, which happens when the target is bound for rendering, the rendersystem looks for an existing one rather than having a separate one for every surface, which is wasteful since only one is used at once (normally). It matches this by looking for depth/stencil buffers with the same format (depth and MSAA settings), and a size which is greater than or equal to the surface wanting to use it. That means if you've had a depth/stencil created for the main window, then your shadow texture asks for one and it's the same basic format / MSAA but smaller than the main window, it can re-use it rather than creating a new one. The code is in, for example, D3D9RenderSystem::_getDepthStencilFor. The problem is that because you're interrupting the render, you want to ring-fence the depth/stencil that you're using for the main view and not have it available for rendering the shadow texture. Because there was no concept before of an interrupted render this was never an issue. You'll need to find a way of tagging that depth/stencil as being 'in use', which probably means changing this approach so that it 'checks out' and 'checks in' the depth/stencil in beginScene and endScene, so that no other surface can grab that depth/stencil until the (interrupted) render has completely finished with it.
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Wed Aug 05, 2009 7:31 pm

sinbad wrote: It matches this by looking for depth/stencil buffers with the same format (depth and MSAA settings), and a size which is greater than or equal to the surface wanting to use it
Ah, thanks for the information. This is useful to know.
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Wed Aug 05, 2009 10:54 pm

Thanks for clearing things up! I started looking into it but this will definitely save me some time.
Hopefully I'll use this information to have shadow casting spotlights (they are the easiest ones) up and running tomorrow...
0 x

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by jacmoe » Thu Aug 06, 2009 1:00 am

Woo-hoo ! :D

I've been following your progress with great interest, Noman :)

I know Omniter has harvested a lot of praise for his elegant wheels, and it has been difficult for you to convey progress in a visual way - until just recently - but I am pretty sure this project will blow the knickers off each and every one of us when it's ready to shine :)
0 x
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
iloseall
Gremlin
Posts: 156
Joined: Sun Sep 14, 2003 3:54 am
Location: Beijing China
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by iloseall » Thu Aug 06, 2009 2:44 am

sinbad wrote:
You'll need to find a way of tagging that depth/stencil as being 'in use', which probably means changing this approach so that it 'checks out' and 'checks in' the depth/stencil in beginScene and endScene, so that no other surface can grab that depth/stencil until the (interrupted) render has completely finished with it.
I think that "check in/out" is not good enough to solve the depth/stencil buffer share question.
How about that we put a can_share_depth flag on buffer or make a share_group_id (int)(default=0,all is try to share) ?
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Thu Aug 06, 2009 6:17 am

jacmoe wrote:Woo-hoo ! :D

I've been following your progress with great interest, Noman :)

I know Omniter has harvested a lot of praise for his elegant wheels, and it has been difficult for you to convey progress in a visual way - until just recently - but I am pretty sure this project will blow the knickers off each and every one of us when it's ready to shine :)
Thanks! But I don't care about the praise. I'm in it for the fun! (and to learn about deferred shading, which forces you to understand the fixed function well enough to implement it on your own, which is cool).
iloseall wrote:
sinbad wrote:
You'll need to find a way of tagging that depth/stencil as being 'in use', which probably means changing this approach so that it 'checks out' and 'checks in' the depth/stencil in beginScene and endScene, so that no other surface can grab that depth/stencil until the (interrupted) render has completely finished with it.
I think that "check in/out" is not good enough to solve the depth/stencil buffer share question.
How about that we put a can_share_depth flag on buffer or make a share_group_id (int)(default=0,all is try to share) ?
You might be right, but I don't feel like I can make a quality decision here, since I'm not aware enough of the possible techniques that might need "smart" depth texture sharing, so I'll probably go with the check in/out approach. I'll keep such options in mind when I implement it to make sure it will be comfortable to extend in the future.
Also, I'm not sure how cross-rendersystem this is. I'll find out soon hopefully...
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Fri Aug 07, 2009 4:27 pm

A wise man once said that one picture is worth a thousand words.
So here is a picture!
Image

This is probably the first screenshot that demonstrates something that really wasn't possible in ogre until now (without bypassing big parts of it and doing almost everything manually).
This single screenshot contains five shadow casting lights (look at the floor under the knots) and screen space ambient occlusion. Its starting to stress my 8600, as you can see I get just over 60 FPS at 1024x768. (Lots of optimizations can be made, I'm going for the simplest techniques on purpose).
In addition to that, there is only one shadow texture in use! It gets prepared on demand for each light, then the light geometry (cone in this case) renders itself using it, allowing the next light to use the same texture for its shadow casting.

Now for the dirty stuff :
Decisions made
- I added the same pattern of pausing/resuming rendering to the RenderSystem API. When the scene manager gets the call, it will send pauseFrame and resumeFrame calls to the RS instead of end/begin frame (the default RS implementation calls end/begin).
- There will be no manual control of depth buffers at this point. OpenGL and DirectX behave differently (they can be changed to behave the same, but currently OpenGL creates a unique depth buffer per FBO, while DirectX is as aggressive as possible)
- I changed the DX implementation of pause/resume to 'keep' the depth texture stored in a different list (and remove it from the global cache temporarily) when pauseFrame is called, so that the next render that might start won't use the depth/stencil buffer still in progress.
- The demo uses the simplest type of shadow mapping that I could implement - the shadow texture is PF_FLOAT16_R and contains linear depth from the light's POV, and then compared during the light render. Smarter things could be implemented, but once again - going for simplicity in the demo.

Stuff to do
- The code I added isn't very structured ATM. Lots of code duplication on the DX rendersystem side that I'll have to sort out.
- Demo stopped functioning correctly under OpenGL. I'll have to backtrack to see why and make sure I'm still in sync.
- Still haven't decided how to handle transparency - I don't want to mess with ogre's internals too much (or add a lot of manual renderqueue-controlling code in the demo) so I'm still thinking about this one.
- Handle shadow casting for point/directional lights - I started with spotlight since its the easiest, hopefully I'll have time to add support for directional/point lights as well.

Lots of work needs to be done, but I'm already happy with what I got done this SoC so far...
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19263
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Fri Aug 07, 2009 5:19 pm

Great work! I'm glad that you got the depth/stencil sharing sorted out. I actually thought GL shared the depth/stencils too, we must have missed that optimisation opportunity then :)

Is it me though, or do a few of the edges look jaggier than the resolution would suggest? It's almost like it's jumping 2 pixels rather than 1 in some cases (see the top decoration of the closest pillar as one example), I wonder if that's related to the horizontal / vertical texel offsets somehow; those are usually handled automatically in the compositor, but maybe there's some additional issue here. Not a top-priority issue, just something I noticed...

Cracking the re-use of a single shadowmap for each light is in particular a major advantage on previously manual deferred renderers, I'm sure people will love this :)
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Fri Aug 07, 2009 5:47 pm

I just realized this depth-sharing also affects my case. It's just that I've re-written my deferred renderer from before, and I haven't bothered with shadow maps yet (previously when I did, I wasn't using efficient depth-based light culling), so the issue didn't quite hit me. I think the cleanest solution would be a "canShareDepthBuffer" flag per-render-target. If true, then it looks to share a depth buffer - if not true, then it uses its own. I'll look into the issue as well.

(And I also noticed the odd jaggies, it does some like some texel offset issue)
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Praetor » Fri Aug 07, 2009 5:57 pm

I'm guessing the optimizations are to be more aggressive about culling which pixels go through the lighting shaders? I remember last time I did deferred I was very pixel shader limited, so cutting down the pixels with clever z-cull and stenciling would help a lot.

For this, though, I agree with using the simpler techniques for demonstration purposes.
0 x
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sat Aug 08, 2009 9:22 am

I finished backtracking the GL problems and solved the bug, so the demo works perfectly under openGL as well. (A vertex shader forgot to check for render target flipping). I was actually quite afraid of this one, glad it turned out to be minor.
This means that the OpenGL rendersystem did not need any modification to have the shadow casting work properly, which (I'm pretty sure) means that I was right that it doesn't share depth/stencil textures aggressively at all.

As for the jaggies, I noticed them as well. I would like to fix the issue, but its slightly less important for me, since its a silly bug somewhere in the demo, that doesn't really disrupt the technological showcase. Hopefully I'll find time to get to it in the cleanup phase at the end of the project.

About the depth/stencil buffer sharing - while a simple (and functional) solution would be for render targets to classify themselves as independent or not, that can also be more expensive than it should be. For example, when rendering shadow maps for a point light, you need 6 render targets. That means that if they all don't share (which they don't), we'll have 7 depth/stencil buffers, instead of the two that are "really" needed.
iloseall's share_group_id idea is probably the correct solution to this problem, but a bit sophisticated. Who would be in charge of setting these share group IDs? Regular shadow casting (shadow textures before scene) don't need them at all, while the deferred shading demo does need them. This can be set up in code, but it seems a bit like we're doing something generic for exactly one use case.
Which is why I currently like sinbad's original idea of checking in/out depth/stencil textures and returning them when done. This means that the number of depth/stencil textures will be the 'stack size' of nested render invocations. (In the case of deferred + shadow : 2). Also transparent to the user code, which is another plus.
Can anyone thing of a use case where this check in/out scheme will not be good enough?
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Sat Aug 08, 2009 11:49 am

Noman wrote:Can anyone thing of a use case where this check in/out scheme will not be good enough?
I don't want it to be transparent, I need a way of manually enabling it. I don't use _renderScene "pausing", instead I simply call _renderScene for shadow maps while in turn manually rendering lights to another target. Therefore, I need some manual way of saying "don't share this with that".
0 x

User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by Noman » Sat Aug 08, 2009 12:02 pm

Yea I was just about to edit my post and add your manual usecase as an answer to my question.
Maybe the solution is the depthStencilBufferGroup ID. Starting to believe that it is.

In other news, theres another thing that I thought about. While not directly related to the compositor framework, it does affect it mostly, and its not a big change.
One of the things that get lost when rendering shadows/compositors is the geometry count. Since every _beginFrame() call resets the geometry count, you can't use Ogre's facilities to count batches/polygons when using advanced render pipelines. I think that all the major rendering-triggering calls (probably camera/viewport/rendertarget's update calls, sceneManager renderScene's call and rendersystem's beginFrame call, I think thats all of them) should have an 'isMain' flag or something similar, and only if that flag is set to true, the geometry/batch count will be reset.
That will allow complex pipelines to count their geometry properly.

Its not a big change, all parameters will be have default values to make sure that current code compiles and behaves the same, but then the compositor/shadow framework can act accordingly, keeping 'total' geometry counts.
I heard some posts on the forums asking why the geometry count goes fubar when compositors are used, and I think this is a simple and elegant solution...
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Sat Aug 08, 2009 12:17 pm

Actually I think it would be more convenient if Ogre exposed the depth/stencil surfaces as something such as DepthStencilTarget. Every RenderTarget could be given a "custom" DepthStencilTarget. If it's NULL, then Ogre will do what it does best and try to share the depth/stencil surface. However, if it's not NULL, then that RenderTarget will use that DepthStencilTarget. This solves even the case of point light shadows since you could create a single DepthStencilTarget and give it to all 6 sides of the point light shadow map.

Besides that, DepthStencilTarget will also allow you to do other operations related to depth/stencil usage.

As for the geometry count issue: why not reset the count only every frame (Ogre::Root::getNextFrameNumber() could be used)? No additional parameters or anything, simply "if we're in the same frame, add the counts - if we're in a new frame, reset the counts".
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19263
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by sinbad » Sat Aug 08, 2009 4:02 pm

I think being more sophisticated about the depth/stencil attachments to render targets is a good idea, but outside of the scope of Noman's GSoC project - so don't distract him ;) In the end, while useful it's only going to be of use to a very small number of people in practice. Noman's existing approach fixes the issue for the purposes of his project, and that's all that's needed right now. We can have a discussion about advanced depth/stencil assignment techniques in another thread of work, separate to the GSoC.

About the geometry counts, I've had a background thought that each begin/end should probably just notify Root of the geometry/batch counts, with the name of the target or some other categorisation 'tag'. Root could then build these up as a list, and the user app could decide what to sum together to analyse the geometry metrics; you could decide to add them all up as one, or analyse what was the main geometry and what was shadow renders, etc. Not something I'd think needs doing now either unless you're looking for things to do.
0 x

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: [SoC 2009 - Accepted] Improve Ogre's Compositor Framework

Post by nullsquared » Sat Aug 08, 2009 8:34 pm

sinbad wrote:I think being more sophisticated about the depth/stencil attachments to render targets is a good idea, but outside of the scope of Noman's GSoC project - so don't distract him ;) In the end, while useful it's only going to be of use to a very small number of people in practice. Noman's existing approach fixes the issue for the purposes of his project, and that's all that's needed right now. We can have a discussion about advanced depth/stencil assignment techniques in another thread of work, separate to the GSoC.
Ha alright, good point - let's not clutter up the thread. But just for the record, Noman, whatever you do, don't make it 100% transparent because then someone else will have to reimplement the same functionality in a different way to make it more flexible :mrgreen: . I'll look into all of this myself, but I'm a complete noob when it comes to raw D3D and OGL, so it'll take me a while to come up with anything useful.
0 x

Locked