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

Threads related to Google Summer of Code
Locked
the_Best_flash
Gnoblar
Posts: 6
Joined: Sat Aug 08, 2009 11:25 pm

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

Post by the_Best_flash »

Very nice work so far. The demo looks great.

However, I did notice a small problem. The render spheres for your point lights appear to be too small. There is a visible boundary where the lights suddenly drop off to zero.

This can be fixed by adding the line:

Code: Select all

outerRadius = (-b + sqrt(b*b - 4*a*(c - 256 ))) / (2*a);
to the "DLight::setAttenuation" function.

Pictures: (Left is before the code was added, right is after)
Image
Keep up the good work.

EDIT:

I almost forgot:

Code: Select all

if( a == 0 )
    if( b != 0 )
        outerRadius = (256 - c) / b;
    else
        outerRadius = mParentLight->getAttenuationRange();
The code also might be more efficient if it took into consideration the light value at 'distance = 0':

Code: Select all

		Ogre::ColourValue diffuse = mParentLight->getDiffuseColour();
		float initial = (diffuse.r > diffuse.g? diffuse.r : diffuse.g);
		initial = (diffuse.b > initial? diffuse.b : initial);

		outerRadius = (-b + sqrt(b*b - 4*a*(c - 256 * initial ))) / (2*a);

		if( a == 0 )
			if( b != 0 )
				outerRadius = (256 * initial - c) / b;
			else
				outerRadius = mParentLight->getAttenuationRange();

This would create smaller spheres for dimmer lights.

This could also be optimized more by decreasing the lower bound value. This calculates the distance until the light is zero, but could be modified to stop at a higher value.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Thanks!
Actually, there is some code that takes care of what you said (in a similar fashion) for point lights, but its currently commented out so that I can test the behavior of the light range param. I'm not sure whether I want to fix a light's attenuation distance based on its falloff parameters. If the user specified that he wants the light to affect only 5 units away, I think that the framework should enforce that even if it means that the final result won't look as good. Its up to the user to tweak his light settings, IMO.

However, I will definitely take a look at that (for the spotlight as well). Perhaps the final code will take the minimum radius of the two, to conserve geometry usage.
I have some more exams coming up so the pace will slow down for the next week (its been hectic as hell for the last 3 weeks), and then back up for a strong finish :)

As for the depth/stencil discussion, I don't think I'll change my current implementation (perhaps just clean it up), but, like the material<->compositor bridge, I will have the future ideas in mind when I do that.
the_Best_flash
Gnoblar
Posts: 6
Joined: Sat Aug 08, 2009 11:25 pm

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

Post by the_Best_flash »

Actually, there is some code...
I see that now, sorry about that.
Perhaps the final code will take the minimum radius of the two
Great idea.

Something else I noticed is that the rotating point lights seem to 'disappear' whenever the camera is positioned on the edge of the bounding sphere. I think this might have something to do with the 'isCameraInsideLight()' function not detecting that the camera is in the sphere soon enough.

Changing this line inside the 'isCameraInsideLight()' function:

Code: Select all

return distanceFromLight <= mRadius;
To this:

Code: Select all

return distanceFromLight <= mRadius + 1.0f;
Seems to have fixed it. The value 1.0f could probably be decreased.

Also I noticed that your spotlight attenuation code isn't using the 3rd spotlight parameter, falloff. I'm not familiar with your version of spotlight falloff, but the version I'm using looks like this:

Code: Select all

	float inner = spotParams.x;
	float outer = spotParams.y;
	float falloff = spotParams.z;
	float cosAlpha = saturate(dot(lightDir.xyz, -objToLightDir));
	
// Compute the spot attenuation factor
    float fSpotAtten = 0.0f; // default value simplifies branch:
    if( cosAlpha > inner )
    {
        fSpotAtten = 1.0f;
    }
    else if( cosAlpha > outer )
    {
        fSpotAtten = pow( (cosAlpha - outer) / (inner - outer), falloff );
    }	
	
	total_light_contrib *= fSpotAtten;
This uses all 3 spotlight parameters. I think you may just need to raise the attenuation calculated in your version to the 'falloff' power.

Third, there seems to be something wrong with the normal mapping in the demo. The first picture is the knot from the original deferred shading demo, and the second is the knot from this demo.
Image
Image

I don't know how to fix it this time. It seems to be a problem that is based on the surface normal (maybe?) because changing the view position does nothing to change the errors. I've compared the nm_ps.hlsl shaders from the original deferred shading demo to your code generated shaders and I didn't notice any differences. The Athena statue isn't as bad, but doesn't look quite the same as the original. However, flat surfaces, such as the floors and walls, seem to be fine.
I have some more exams coming up so the pace will slow down for the next week
Good luck with those.
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

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

Post by nullsquared »

the_Best_flash wrote:
Actually, there is some code...
...
Just for the record, I find it a lot easier to just use "ranged" lights. Forget about quadratic attenuation and all that, simply have the light intensity become 0 at a certain "light radius" (or "range" if that's what you want to call it). This makes everything a lot easier - from tuning the light inside the scene, to calculating the bounding sphere/cone and so on.
Third, there seems to be something wrong with the normal mapping in the demo. The first picture is the knot from the original deferred shading demo, and the second is the knot from this demo.
Image
Image

I don't know how to fix it this time. It seems to be a problem that is based on the surface normal (maybe?) because changing the view position does nothing to change the errors. I've compared the nm_ps.hlsl shaders from the original deferred shading demo to your code generated shaders and I didn't notice any differences. The Athena statue isn't as bad, but doesn't look quite the same as the original. However, flat surfaces, such as the floors and walls, seem to be fine.
That looks fine to me, what do you think is wrong?
the_Best_flash
Gnoblar
Posts: 6
Joined: Sat Aug 08, 2009 11:25 pm

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

Post by the_Best_flash »

The first one is correct.

The second one looks very different from the first.

It looks much 'flatter' especially in the closest bend, and overall it seems to have a lower quality. I've tried using a higher resolution bump map that I generated, but it still has strange artifacts.

Left is the current demo, right is what the previous Demo (included with OGRE 1.6) looks like.

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

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

Post by nullsquared »

The knot looks like it's using a different normal map :/

As for Athena, it looks like the geometry is at a different LOD.
the_Best_flash
Gnoblar
Posts: 6
Joined: Sat Aug 08, 2009 11:25 pm

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

Post by the_Best_flash »

As far as I can tell the normal maps for the knot is the same, and I was about the same distance from the Athena statue...

Maybe there is a mipmap/LOD problem?
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Perhaps... Again, these issues worry me less. These will wait till final touchups etc.
I did read up and notice that a light's attenuation range is supposed to be used for scene-management purposes only - meaning to just figure out which objects are affected by which lights. They are not supposed to affect the lighting calculations at all. I don't know if I should change the deferred shading system back to ignore this flag for its calculation purposes. I still need to decide where to go with this.
(Still during test period, so no heavy progress)
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Hmmm...
Trying to add support for directional light shadows, just one problem - I don't have access to the shadow camera's position (this thread already discusses the problem, but without a solution). Does anyone have any idea how to solve it?
(I can add another auto constant type to ogre, but is there a simpler way using the current techniques?)

[Edit]In the meantime, I generate the shadow camera (again) and set the param manually in my demo code. Not too horrible...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Well, I implemented directional light shadow casting. And it works. But it doesn't look very good.

This is the shadow map after I tweaked the settings and got to a pretty good state for the scene :
(Using completely standard DSM)
Image

Next, I print out

Code: Select all

float D = shadowDistance - distanceFromLight + 0.5;
So lit pixels should be white or gray (since they are closer to the light than the shadow is)
And this is what I get :
Inside:
Image
Outside :
Image

The complete scene looks like this :
Inside :
Image
Outside :
Image

Which is pretty bad.
I don't have much experience with shadows... What are the chances of having decent looking directional light shadows without a more advanced shadow algorithm? (PSSM etc)
I'm considering dropping directional light shadows from the demo, since directional lights aren't the classic usecase of an indoors deferred scene...
(And I don't want this to be a shadow-centric example)
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

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

Post by nullsquared »

What resolution is it and what format?
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

The screenies I took were 1024x1024, PF_FLOAT32_R (Again, 'trivial' linear depth shadow mapping)
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
x 3
Contact:

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

Post by Praetor »

Especially the outside shot, I think that looks fine. With just normal shadowmaps that kind of shadow quality is what I'd except. You simply have some depth problems on your geometry. Are you render front or back faces into the shadow map? With normal shadow mapping you might want to try back faces. And, are you using any sort of depth bias either when rendering the shadow map or when doing the shadow comparison? You may need a little bias.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

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

Post by sinbad »

Most of the artefacts look to be down to biasing problems. It looks like you're rendering front faces - rendering backfaces will save you lots of biasing headaches. With front faces you have to bias more, and need to gradient-bias a lot of the time (the Demo_Shadows shadowmapping shader does this). Since I wrote the shaders for that I've worked on a lot more projects using depth shadowmaps and I always go with backfaces now, as well as using linear depth. The Demo_Shadows depth shadowmapping example really needs throwing away and replacing now.

I don't really understand the issue with camera position. Since the shadowmap depths are in light space, and the texWorldViewProj matrix binding will let you transform from any world space position to light space, I'm not sure what else you would need.

And slightly tangentally, here's the sort of technique I want to implement with your system eventually: http://graphics.cs.uiuc.edu/~kircher/in ... _paper.pdf . I've never really been fond of full deferred rendering (losing MSAA hurts too much) and this latest evolution on light prepass is very interesting. Some of the discontinuity filtering techniques may also work well for filtering SSAO - in the past I've used a depth comparison to do it (only accept SSAO filter samples where depth is within a given range, so no bleeding across distant objects). All of it should be easier to implement with your changes I hope.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Finished final exam today! Woohoo!
In more GSoC related news, the 'pencils down' date was officially yesterday. So, I'm currently just cleaning up code, making sure it is ready for submission.
It's more important for me to clean up the code that goes into OgreMain, as that is the most important contribution. The demo, while cool and important as an educational factor, will cause less damage if I'm a bit less strict on commenting etc.
When I finish that, I'll have something easily submittable to google, and will resume working on the demo. Not sure if I'll finish up support for directional/point lights as they do complicate stuff a bit, and spotlight shadow casting is enough to demonstrate how to tackle shadow casting (design wise) in the framework.
A simple usage of an interface often has a better educational value than a complicated one, since its easier to understand.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Started working on the article...

http://www.ogre3d.org/wiki/index.php/Deferred_Shading

The idea is that this will not be 'officially' related to the GSoC project, as once the merge will be done its just another demo and a few more API options in the infrastructure, so people should be able to read about it independently.
Its not done yet (I'd say, about halfway there currently, and then a cleanup when I get to the end) but I think it is shaping up to be a good explanation of how to create an advanced pipeline using ogre, which is something that wasn't really explained so far...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Finished the first draft of the article. It is available in the address in the previous post.
If anyone has any comments, this is a good place to put them...
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

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

Post by sinbad »

Looks good. I would personally be interested in an example of how you might apply the new features to Deferred Lighting / Light Pre-Pass Shading (rather than full deferred shading), which would presumably go in the 'extending' section.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Hm... After reading the inferred lighting paper to greater detail, I think that this project is on the right way to make that possible, but some of the things discussed (specifially speaking, the material<->compositor bridge) are required to make it possible.

The 3rd stage of the process (material pass) requires rendering the objects in the scene while addressing the G-Buffer (and L-Buffer) textures. This is one of the two things discussed in the material<->compositor bridge (the other being individual materials being able to trigger RTT targeting passes).

The best way to tackle this (IMO) is to introduce a new content_type option for textures (the current ones being regular and shadow) for compositors, which will allow a material to address a compositor (the connection could be made by compositor name, or by compositor texture index, that will be linked to the input textures of the render_scene directive).

This was discussed in this thread, but mainly because of time/quality constraints, did not make it into the project.

However, it does bring an important point. I should scan this thread and its discussions and add a "future work" section to the wiki page with all the ideas and conclusions reached during the project that did not make it in. There were some very good discussions along the road...
[Edit] Cleaned up the wiki page (updated it to be current) and added the main ideas that I found in the thread that didn't make it in.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

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

Post by sinbad »

Yes, I think you're right- the sequencing options are probably already there, and obviously the sharing / persistence of the compositor textures was a core element of the project, but what's missing is the ability to link up one of the output compositor textures to a texture unit on a regular material. A new content_type is certainly the way to go for that. I think as you say you'd want to do the linking in the render_scene pass, perhaps by having the ability to link the locally named RTT to a 'tag' name which is referenced in the content_type on the material (this means the linking is quite flexible while still being straight forward). This is definitely an area I would like to be explored in the future.

Having mulled over the inferred lighting paper for a week or so, my personal opinion is that I prefer light pre-pass (which is basically the same, except that the light accumulation texture is at full resolution). I think for some consoles inferred lighting will have some advantages because of the lower memory requirements, but the extra work you have to do to deal with the mismatched resolutions has its own cost. The dithering approach to transparent objects is interesting though, although again I wonder whether in practice it makes much perceptible difference versus a separate forward render with less lighting detail, and whether the dithering becomes too noticeable in some cases.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

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

Post by Noman »

Its almost ironic that I really didn't care much for performance in the GSoC project.
I always saw the improvements to the framework as 'performance geared design improvements' that will allow people to implement various techniques for efficiency.
Even in the demo, I always chose simplicity over performance to make it as understandable as possible.

I really don't see any way to measure these techniques against each other except implementing them and running them one against the other on the target platforms.

The addition we are talking about is part of the future work section in the project wiki page. The minor details (by name or by index etc) can be decided on during implementation, but obviously will not be part of the GSoC project.
Honestly, I don't think its hard to implement. The only reason I'm not gonna add it 'for fun' is that I don't want to add a feature to Ogre without testing it. Which, in this case, means to implement the paper. And that is a quite a bit of work...
User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA
x 11

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

Post by nullsquared »

While on the topic of deferred lighting, an interesting article that compares it with full-on deferred shading: http://gameangst.com/?p=141
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
x 3
Contact:

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

Post by Praetor »

I'm actually quite interested in the lower-resolution light-buffer upsampling technique used in Inferred Lighting. It seems that it could be used for a variety of upsampling tasks beyond the light buffer. I definitely agree that the transparency dithering seems fragile and might not be all that much better in practice than another forward pass. I suppose unless you have an insane amount of transparent objects.

Perhaps it's your pixel-pushing beast, but I find down-sampling before pixel shading gives enormous speedups. I really want to see how much the speedups get cut into using the complicated upsampling from the paper. Obviously if that process is more expensive than the gains you get from downsampling then it isn't worth it.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

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

Post by sinbad »

nullsquared wrote:While on the topic of deferred lighting, an interesting article that compares it with full-on deferred shading: http://gameangst.com/?p=141
Yeah, I've read this before and I don't personally agree with it based on everything else I've read, and my own relatively simple experiments with deferred rendering. Firstly, he's mostly considering performance, and the main beneficiary of any performance difference was the PS3 because it turned out to be vertex-bound (although it appears that greater SPU usage would have amortised that). Almost no other system out there capable of deferred rendering is likely to be vertex bound so this is moot.

He talks about lighting accuracy, and he's completely correct. However, I challenge most players / users to notice the difference - when you put the shots next to each other you can see the difference (a common one is lack of per-light specular colour) but in practice there's little noticeable effect. If Crytek can live with it, I think I can.

Lastly, he completely ignores MSAA support, which is my #1 reason for not liking full deferred shading very much. Given that increasing the resolution in deferred shading gets very expensive, you're almost always stuck with jaggies which IMO are unacceptable in modern renders. Of course you could add enough additional post-processing to partially obscure them (More bloom and motion blur! Argh, my eyes! ;)) but I don't think we should consider a lack of MSAA palatable to most viewers in 2009.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

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

Post by Assaf Raman »

Hi Noam Gat,
We have processed the evaluation for your project named Improve Ogre's Compositor Framework with OGRE.
Congratulations, from our data it seems that you have successfully passed the Final Evaluations. Please contact your mentor to discuss the results of your evaluation and to plan your goals and development plan for the rest of the program
Greetings,
The Google Open Source Programs Team
Watch out for my OGRE related tweets here.
Locked