Features for deferred shading
-
- Halfling
- Posts: 74
- Joined: Sun Sep 07, 2008 5:09 pm
Features for deferred shading
Hi there!
Deferred shading with OGRE is not a solved problem, and the sample project is not very efficient (as is my own project). I'd request 2 features that would allow for a cleaner and more efficient implementation of deferred shading. I am also willing to provide an implementation, but I would first like to discuss these.
(1) Disable the rendering of the scene for a render target. Currently, the dominant approach to deferred shading with OGRE seems to be to define a compositor that combines the information from the G-buffer to create the final image. However, when updating the main render target, the scene is also always rendered. One can set a visibility mask to 0, but I think the scene graph will then still be traversed; plus this has its own drawbacks (see 2). In short, there is no way to say "I want only execute the compositor for this render target".
In my opinion, it is perfectly legal for any render target to only have a compositor rendered on it, but it seems that there must always be a camera attached to the viewport. This should be optional. As an alternative, one may have 2 properties, such as "sceneRenderingEnabled" and "compositorRenderingEnabled".
(2) Allow to query lights for a specific frustum / in range. Currently, the only thing the scene manager has to offer is to query the lights "affecting the frustum". This however, returns 0 lights if one sets the visibility mask to 0 (see above). Also, it is not clear that the main render target's frustum needs to correspond to the frustum used to fill the G-buffer.
I would like to discuss these features with you in respect to whether you would also find them useful and whether they are feasible to implement.
Deferred shading with OGRE is not a solved problem, and the sample project is not very efficient (as is my own project). I'd request 2 features that would allow for a cleaner and more efficient implementation of deferred shading. I am also willing to provide an implementation, but I would first like to discuss these.
(1) Disable the rendering of the scene for a render target. Currently, the dominant approach to deferred shading with OGRE seems to be to define a compositor that combines the information from the G-buffer to create the final image. However, when updating the main render target, the scene is also always rendered. One can set a visibility mask to 0, but I think the scene graph will then still be traversed; plus this has its own drawbacks (see 2). In short, there is no way to say "I want only execute the compositor for this render target".
In my opinion, it is perfectly legal for any render target to only have a compositor rendered on it, but it seems that there must always be a camera attached to the viewport. This should be optional. As an alternative, one may have 2 properties, such as "sceneRenderingEnabled" and "compositorRenderingEnabled".
(2) Allow to query lights for a specific frustum / in range. Currently, the only thing the scene manager has to offer is to query the lights "affecting the frustum". This however, returns 0 lights if one sets the visibility mask to 0 (see above). Also, it is not clear that the main render target's frustum needs to correspond to the frustum used to fill the G-buffer.
I would like to discuss these features with you in respect to whether you would also find them useful and whether they are feasible to implement.
-
- Halfling
- Posts: 74
- Joined: Sun Sep 07, 2008 5:09 pm
Re: Features for deferred shading
Ok, I guess it's not interesting?
Does nobody play around with deferred shading and find it suboptimal to implement?
Does nobody play around with deferred shading and find it suboptimal to implement?
-
- OGRE Expert User
- Posts: 1671
- Joined: Mon Jan 21, 2008 10:26 pm
- x 50
Re: Features for deferred shading
To put it simply I don't use compositor framework. It's good for some purpose. But when you have very specific needs, the simplier is just to do it normally. Otherwise your mimic-ing completely everything with a combination of Listeners, where you could have done it simply manually. Personnaly, I have never quite understood why people bother to use the compositor framework... I find it harder to understand than the direct calls.
I know that I am not alone thinking that.
Why would someone spend time learning something that exists only in Ogre and that does not gives any gain ? If you go the natural way, not only you have complete understanding and control of what you do, but what is more, you can reuse that knowledge with other 3D engines easily...
That is my answer to your question.
I suppose Noman would have a completely opposite point of view .
I know that I am not alone thinking that.
Why would someone spend time learning something that exists only in Ogre and that does not gives any gain ? If you go the natural way, not only you have complete understanding and control of what you do, but what is more, you can reuse that knowledge with other 3D engines easily...
That is my answer to your question.
I suppose Noman would have a completely opposite point of view .
Tutorials + Ogre searchable API + more for Ogre1.7 : http://sourceforge.net/projects/so3dtools/
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0
Corresponding thread : http://www.ogre3d.org/forums/viewtopic. ... 93&start=0
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: Features for deferred shading
Madmarx: You have totally misunderstood what the compositor framework is for.
I think it all started with Manuels PostfilterManager:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=12184
I am not really sure how it evolved after that, but it led to the compositor framework which offers an elegant way of chaining postfilter effects:
One pass is input to another pass and so on.
That's where the compositor framework does it's job.
It shouldn't be used for everything, though - of course.
I think it all started with Manuels PostfilterManager:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=12184
I am not really sure how it evolved after that, but it led to the compositor framework which offers an elegant way of chaining postfilter effects:
One pass is input to another pass and so on.
That's where the compositor framework does it's job.
It shouldn't be used for everything, though - of course.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: Features for deferred shading
While it is possible to do deferred shading with Ogre, the fact is that Ogre is a forward renderer and is implemented as such.
-
- Halfling
- Posts: 74
- Joined: Sun Sep 07, 2008 5:09 pm
Re: Features for deferred shading
That may be its original design, but wouldn't it still be worth considering features that enable a better implementation of deferred shading? DS and similar techniques are gaining practical importance (Unreal Engine 3, CryEngine 3) and the graphics world is always changing. For example, the fixed function pipeline is practically dead and causes nothing but bloated interfaces.
From time to time, OGRE will have to evolve.
From time to time, OGRE will have to evolve.
-
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: Features for deferred shading
Ogre is a general-purpose rendering engine; it evolves in directions that are generally-applicable. With a limited development staff, all working on their own time, features and evolutionary changes are chosen that are most generally applicable, and deferred shading, regardless how much one user may like or how trendy it may be right now, is not generally applicable.
It is also incorrect to claim that fixed-function is "dead". You may not use it personally, but that doesn't mean that no one else does. There is still plenty of DX9-class (and older) hardware in the world that requires this support.
It is also incorrect to claim that fixed-function is "dead". You may not use it personally, but that doesn't mean that no one else does. There is still plenty of DX9-class (and older) hardware in the world that requires this support.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: Features for deferred shading
I am not really sure what you're telling us, Xavier, but is deferred rendering not going to replace regular forward rendering?
It sounds more flexible and less error prone.
Or are you saying that Ogre 3D will soon become obsolete (read: in 5 years) as soon as deferred rendering gains foothold?
Or, will it be possible to restructure Ogre itself - like flipping the current on a toggle switch - to become a deferred renderer?
(Or - a renderer which does deferred shading).
It sounds more flexible and less error prone.
Or are you saying that Ogre 3D will soon become obsolete (read: in 5 years) as soon as deferred rendering gains foothold?
Or, will it be possible to restructure Ogre itself - like flipping the current on a toggle switch - to become a deferred renderer?
(Or - a renderer which does deferred shading).
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Moderator
- Posts: 9481
- Joined: Fri Feb 18, 2005 2:03 am
- Location: Dublin, CA, US
- x 22
Re: Features for deferred shading
What on earth would make you say that?jacmoe wrote:I am not really sure what you're telling us, Xavier, but is deferred rendering not going to replace regular forward rendering?
-
- Halfling
- Posts: 74
- Joined: Sun Sep 07, 2008 5:09 pm
Re: Features for deferred shading
Well, it's not completely unlikely. I guess nobody really knows what the future is.What on earth would make you say that?
A fact is that deferred shading is not just a "trend". The two biggest game engines use it (or a similar technique), because it has various very practical advantages. I don't think that Unreal Engine will be deferred-shaded this day and then again be completely forward-rendered another day.
Forward renderering *may* die, but I think it is very difficult to predict. Right now, DS is an important rendering technique and could be better supported with simple changes to OGRE. That's my whole point. However, this makes only sense, if at least a part of the OGRE community is interested in this. Since few people answered and even fewer people made suggestions to bring DS on, it seems not so.
-
- OGRE Retired Moderator
- Posts: 20570
- Joined: Thu Jan 22, 2004 10:13 am
- Location: Denmark
- x 179
Re: Features for deferred shading
Well..xavier wrote:What on earth would make you say that?jacmoe wrote:I am not really sure what you're telling us, Xavier, but is deferred rendering not going to replace regular forward rendering?
I am saying it because it is increasingly used in modern games.
Sony Entertainment and Crytek, for instance.
The advantages is that it simplifies the rendering pipeline a lot.
And deferred lighting means that you can have (dynamic) lightsources without creating a complex chain of shaders taking N lightsources into account.
Of course, deferred shading is not perfect as it introduces several problems of its own, but IMO the simplified pipeline makes up for it's shortcomings.
So, knowing not a lot about deferred shading, I am just enquiring into the possibilities.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 116
Re: Features for deferred shading
My project I mix deferred and forward rendering (Deferred for lots of decorative little point lights, forward for big scene shadow-casting spotlights.) Ogre seems fine for deferred shading to me, once I got the manual MRT thing sorted. I stay away from compositors, I don't really see their point if you know how to do RTT and MRT. But hey, that's just me.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
-
- Kobold
- Posts: 36
- Joined: Thu Sep 25, 2008 10:34 am
- Location: Russia. Nakhodka.
- x 4
Features for deferred shading
Add PSSM (with PCF filtering) in Deferred Shading example please.
And... point light with shadows.
And... point light with shadows.
-
- Gnome
- Posts: 389
- Joined: Mon Jul 26, 2010 10:53 pm
- x 22
Re: Features for deferred shading
I'm interested in deferred shading. It seems like it's probably better for me to implement this myself manually without compositors.
-
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 116
Re: Features for deferred shading
I wrote a wiki article on setting up the MRT without compositors. You don't necessarily need MRT, but it makes a big speed difference when you're rendering the same scene multiple times to get your depth, normal, diffuse etc for deferred shading.LBDude wrote:I'm interested in deferred shading. It seems like it's probably better for me to implement this myself manually without compositors.
http://www.ogre3d.org/tikiwiki/Multiple+Render+Targets
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
-
- Gnome
- Posts: 389
- Joined: Mon Jul 26, 2010 10:53 pm
- x 22
Re: Features for deferred shading
Thanks. I most definite will need MRT for deferred rendering.
-
- OGRE Retired Team Member
- Posts: 714
- Joined: Mon Jan 31, 2005 7:21 pm
- Location: Israel
- x 2
Re: Features for deferred shading
Didn't see this topic until now, some interesting debate in here
I'll wear the "pro-compositor" hat for this post, and state the following :
1 - Understand the Viewport/Camera/RenderTarget decoupling. (This is also important if you want to implement DS without compositors). If a correct compositor chain is set up, the 'forward' rendering sequence will not take place. Debug the deferred shading sample with PerfHUD to see that.
2 - Compositors can be used to set up an advanced rendering pipeline. Once the framework is understood, the separation of the deferred pipeline into the several stages (G-Buffer, lighting and postprocessing) is achieved and you can focus on each on independently of the rest. Yes, you can set this up in code as well, but you have a lot of manual work to do.
However, even during the SoC project, we saw that Ogre isn't completely built for changing the pipeline that way. Things like scene traversal and render queue management are too tightly coupled at the moment. SceneManager should (eventually) be split up into smaller pieces, so that one component is in charge of understanding which objects need to be rendered, and a different one actually does that. The downside is that the scene might be traversed several times per frame when using the compositor framework. This can be avoided with manual work, but you are bypassing most of Ogre if you are doing this, and then you are pretty much using Ogre as a DX/GL abstraction layer and not much more.
If I had to implement a deferred pipeline for a project today I honestly WOULD use the compositor framework, as it saves a lot of time. But I agree that Ogre's rendering pipeline needs to be redesigned to be more flexible. But that is a huge change in Ogre...
I'll wear the "pro-compositor" hat for this post, and state the following :
1 - Understand the Viewport/Camera/RenderTarget decoupling. (This is also important if you want to implement DS without compositors). If a correct compositor chain is set up, the 'forward' rendering sequence will not take place. Debug the deferred shading sample with PerfHUD to see that.
2 - Compositors can be used to set up an advanced rendering pipeline. Once the framework is understood, the separation of the deferred pipeline into the several stages (G-Buffer, lighting and postprocessing) is achieved and you can focus on each on independently of the rest. Yes, you can set this up in code as well, but you have a lot of manual work to do.
However, even during the SoC project, we saw that Ogre isn't completely built for changing the pipeline that way. Things like scene traversal and render queue management are too tightly coupled at the moment. SceneManager should (eventually) be split up into smaller pieces, so that one component is in charge of understanding which objects need to be rendered, and a different one actually does that. The downside is that the scene might be traversed several times per frame when using the compositor framework. This can be avoided with manual work, but you are bypassing most of Ogre if you are doing this, and then you are pretty much using Ogre as a DX/GL abstraction layer and not much more.
If I had to implement a deferred pipeline for a project today I honestly WOULD use the compositor framework, as it saves a lot of time. But I agree that Ogre's rendering pipeline needs to be redesigned to be more flexible. But that is a huge change in Ogre...
-
- Gold Sponsor
- Posts: 1894
- Joined: Sun Mar 08, 2009 5:25 am
- x 116
Re: Features for deferred shading
Probably a little off topic, but anyway...This can be avoided with manual work, but you are bypassing most of Ogre if you are doing this, and then you are pretty much using Ogre as a DX/GL abstraction layer and not much more.
Speaking as a user of Ogre rather than a developer of Ogre, I actually do think of Ogre largely as a DX/GL abstraction layer. In fact, that was almost the sole reason I took up Ogre in the first place, rather than XNA or pure DX or GL coding.
I think of Ogre as having three "components," or types of things it does for the user.
1. DX/GL abstraction layer that allows you to program for both with minimal fuss. Setting up screens and viewports without worrying about underlying mechanics.
2. Very useful systems that any game and many other projects will need, usually math or parsing heavy. Stuff like animation, materials, nodes and vectors, quaternions, and frustum functions. Vital stuff that would take for ever to code up from scratch (and, if I coded it, probably be poorly done.)
3. Stuff that's supposed to make it easier, but really just traps you. Stuff you can already do with 1+2. Two examples that come to mind immediately are shadow maps and compositors.
I love 1 and 2 but I'm not a big fan of 3. If I can already easily set up shadow mapping and post processing using a bit of RTT via 1 and 2, then making me learn new systems like compositors just wastes my time. I ended up with far more control, far more customization options, and less different systems to deal with, when I changed all my shadows and post processing over to totally manual RTT setups.
Instead of hard coding these kinds of things into Ogre, I think samples that demonstrate how to do it manually would be much handier. I actually think this is simpler for the user than having to learn special purpose hardwired systems.
But maybe that's just me. Not trying to start a flame war or anything, just saying as a user how I like to actually code Ogre projects.
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.
-
- Silver Sponsor
- Posts: 1141
- Joined: Tue Jul 06, 2004 5:57 am
- x 151
Re: Features for deferred shading
Do not underestimate this. A lot of people are attracted to this or don't have the time and/or knowledge to delve deep into the matter. I even would even encourage to have more of these things. Ogre is not really a competitor to Unity or other engines (apples/pears), but these engines can be used as an alternative for Ogre, because they do contain these easy 'shortcuts'. Not to start a flame here.3. Stuff that's supposed to make it easier, but really just traps you. Stuff you can already do with 1+2. Two examples that come to mind immediately are shadow maps and compositors.
Gui generator tool https://github.com/spookyboo/Magus ==> Windows binaries https://github.com/spookyboo/Magus_bin
HLMS editor https://github.com/spookyboo/HLMSEditor ==> Windows setup https://github.com/spookyboo/HLMSEditor ... e?raw=true
HLMS editor https://github.com/spookyboo/HLMSEditor ==> Windows setup https://github.com/spookyboo/HLMSEditor ... e?raw=true
-
- Gnoblar
- Posts: 4
- Joined: Thu Sep 22, 2011 9:31 am
Re: Features for deferred shading
Agree. It's not that I don't like Unity, it's just that I don't learn anything with it, I prefer to achieve little steps with Ogre or SFML instead.spookyboo wrote:Do not underestimate this. A lot of people are attracted to this or don't have the time and/or knowledge to delve deep into the matter. I even would even encourage to have more of these things. Ogre is not really a competitor to Unity or other engines (apples/pears), but these engines can be used as an alternative for Ogre, because they do contain these easy 'shortcuts'. Not to start a flame here.3. Stuff that's supposed to make it easier, but really just traps you. Stuff you can already do with 1+2. Two examples that come to mind immediately are shadow maps and compositors.
-
- Orc
- Posts: 424
- Joined: Wed Aug 01, 2007 8:13 pm
- Location: Venice, CA, USA
- x 7
Re: Features for deferred shading
I was about to make my own thread asking for compositor improvements to support deferred shading until I found this thread.
I think anyone avoiding the compositors either (1) does not understand its goals OR (2) realizes that it is not completely flexible yet. A post-processing framework is part of any rendering engine worth its weight. OGRE was smart to expose the post-processing commands via script. Deferred shading should be added with compositor scripts because it allows you to change your setup very quickly. To test your rendering, it is a huge advantage to go back and forth from forward shading and deferred, or add different visualization schemes by just modifying the script. If more people were using the compositor we would probably have a very flexible script by now.
@yeahRight: Your points are insightful. I was just debugging OGRE with my compositor setup for deferred shading and I think the scene graph is being updated when it should not. I agree that this and other things can be improved so that compositors can be used to implement deferred shading easily.
I think we will need new keywords in the script to handle deferred shading tasks. For example, when rendering the G-buffer, there should be a keyword to disable light frustum checks. Also, I recently had to replace 'render_quad' with my own command ('render_smartquad') because the built-in Rectangle-Renderable does not allow light and camera info to be passed to your shaders when illuminating the G-buffer. We will need a clear way to define geometry and materials for lights. I do not think the light geometry should ONLY be built by the engine. It should be possible to customize for the user. I could see a command similar to 'render_scene' that treats the scene entities as lights (preparing shadows and setting up projection matrices).
Please feel free to PM me if anyone is working on the compositor scripts. I'd like to add some features to make deferred shading easy.
I think anyone avoiding the compositors either (1) does not understand its goals OR (2) realizes that it is not completely flexible yet. A post-processing framework is part of any rendering engine worth its weight. OGRE was smart to expose the post-processing commands via script. Deferred shading should be added with compositor scripts because it allows you to change your setup very quickly. To test your rendering, it is a huge advantage to go back and forth from forward shading and deferred, or add different visualization schemes by just modifying the script. If more people were using the compositor we would probably have a very flexible script by now.
@yeahRight: Your points are insightful. I was just debugging OGRE with my compositor setup for deferred shading and I think the scene graph is being updated when it should not. I agree that this and other things can be improved so that compositors can be used to implement deferred shading easily.
I think we will need new keywords in the script to handle deferred shading tasks. For example, when rendering the G-buffer, there should be a keyword to disable light frustum checks. Also, I recently had to replace 'render_quad' with my own command ('render_smartquad') because the built-in Rectangle-Renderable does not allow light and camera info to be passed to your shaders when illuminating the G-buffer. We will need a clear way to define geometry and materials for lights. I do not think the light geometry should ONLY be built by the engine. It should be possible to customize for the user. I could see a command similar to 'render_scene' that treats the scene entities as lights (preparing shadows and setting up projection matrices).
Please feel free to PM me if anyone is working on the compositor scripts. I'd like to add some features to make deferred shading easy.
-
- Gnoblar
- Posts: 4
- Joined: Fri Aug 30, 2013 4:42 pm
Re: Features for deferred shading
I am just recently getting back into game development after almost 5 years of inactivity (like as if I could get a job doing that). This year I did quite a lot of research into rendering, computing with CUDA, modelling with blender, etc. When I started game development 10 years ago there was almost no such thing as deferred shading, and if it even existed it was in the stages of research or confined to ray tracing.
Now my understanding of deferred shading is that you separate the components of the lighting equation into separate passes, one for the normals (buffer) one for the colour/material/texture and another for the depth(often much better using mrt). The components of the lighting equation are then combined (like ambient + diffuse + secular) at the end, and the result is displayed as a screen aligned textured quad. The benefits of the approach are clearly known to everyone who reads this thread as the ability to have many point light sources in one scene. I do think the demo demonstrates this feature...other benefits include the ability to avoid clipping in later rendering passes, and the surface normal information can be reused by advanced graphics programmers for light transport phenomena (not my style, but its interesting to research 2nd bounce dynamics if you want to try to compete with the high end engines or shader demo). The depth channel can also allow you to compute screen based ambient occlusion and other post processing effects, also because it is a software depth buffer you can set higher z-depth resolution. Another advantage (which is also possibly a disadvantage) is that all the materials in the scene are rendered with an uber shader, much like the rtss built into ogre. The disadvantages include the fact that you know have scenes that support more point light than you have shadows for, and the material system might have limitations. One way around the material limitations is shown in the most recent Nvidia opengl sdk (they didn't release the opengl samples with their most recent sdk, however opengl 4.2 looks about as good as dx11) in the Christmas tree sample, where the shader writes some simple meta data into the alpha channel and that is used with an 'if' statement to branch into a simple reflectance spheremap for the baubles - this technique could be extended for more materials.
I Really think forward rendering is a better simulation of lighting, however I think def rendering is a worthy optimization that should be completely possible for experimentors and advanced high end graphics programmers
Now my understanding of deferred shading is that you separate the components of the lighting equation into separate passes, one for the normals (buffer) one for the colour/material/texture and another for the depth(often much better using mrt). The components of the lighting equation are then combined (like ambient + diffuse + secular) at the end, and the result is displayed as a screen aligned textured quad. The benefits of the approach are clearly known to everyone who reads this thread as the ability to have many point light sources in one scene. I do think the demo demonstrates this feature...other benefits include the ability to avoid clipping in later rendering passes, and the surface normal information can be reused by advanced graphics programmers for light transport phenomena (not my style, but its interesting to research 2nd bounce dynamics if you want to try to compete with the high end engines or shader demo). The depth channel can also allow you to compute screen based ambient occlusion and other post processing effects, also because it is a software depth buffer you can set higher z-depth resolution. Another advantage (which is also possibly a disadvantage) is that all the materials in the scene are rendered with an uber shader, much like the rtss built into ogre. The disadvantages include the fact that you know have scenes that support more point light than you have shadows for, and the material system might have limitations. One way around the material limitations is shown in the most recent Nvidia opengl sdk (they didn't release the opengl samples with their most recent sdk, however opengl 4.2 looks about as good as dx11) in the Christmas tree sample, where the shader writes some simple meta data into the alpha channel and that is used with an 'if' statement to branch into a simple reflectance spheremap for the baubles - this technique could be extended for more materials.
I Really think forward rendering is a better simulation of lighting, however I think def rendering is a worthy optimization that should be completely possible for experimentors and advanced high end graphics programmers
-
- Gnoblar
- Posts: 2
- Joined: Sun Mar 20, 2011 7:20 pm
Re: Features for deferred shading
@EnergyIQ: I disagree with you on a lot of things, so I typed up some reasons and disadvantages of DS and also a short description.
Reasons to use DS:
Standard DS consists of 2 phases: The geometry-phase (Draw the geometry and rendering to the "G-buffer" and the lighting Phase (For earch light render a quad and calculate the lighting with the "G-buffer").
This reduces the Overall complexity and only visible fragment programs are executed! (which is important for expensive shaders). Furthermore the G-buffer can be used for approximating ambient occlusion, depth-of-field,... .
The performance for lights can be increased by drawing smaller quads or other bounding volumes instead of a fullscreen quad. Another important optimisation is the reduction of data which is saved in the G-buffer. E.g. instead of saving the position calculate it using depth and camera.
Light-pre pass and depth-pre passes can be added as needed
Disadvantages:
My conclusion
Nobody knows what the future holds, but DS is definetely state-of-the-art for current game engines. I'm not an OGRE developer, but I think OGRE is constructed as a forward renderer and changing that is probably to much work. I don't think the benefits justify this right now. Let's see...
Reasons to use DS:
- Shading is expensive (many lights, procedural textures, 3d datastructures,...)
- Reducing complexity by separating geometry and lighting
- Many light sources
Standard DS consists of 2 phases: The geometry-phase (Draw the geometry and rendering to the "G-buffer" and the lighting Phase (For earch light render a quad and calculate the lighting with the "G-buffer").
This reduces the Overall complexity and only visible fragment programs are executed! (which is important for expensive shaders). Furthermore the G-buffer can be used for approximating ambient occlusion, depth-of-field,... .
The performance for lights can be increased by drawing smaller quads or other bounding volumes instead of a fullscreen quad. Another important optimisation is the reduction of data which is saved in the G-buffer. E.g. instead of saving the position calculate it using depth and camera.
Light-pre pass and depth-pre passes can be added as needed
Disadvantages:
- Anti-aliasing not "out of the box". Though MLAA is ok
- Memory consumption from the G-buffer
My conclusion
Nobody knows what the future holds, but DS is definetely state-of-the-art for current game engines. I'm not an OGRE developer, but I think OGRE is constructed as a forward renderer and changing that is probably to much work. I don't think the benefits justify this right now. Let's see...
-
- Gremlin
- Posts: 196
- Joined: Tue Aug 08, 2006 6:45 pm
- x 14
Re: Features for deferred shading
Anti-Aliasing really isn't an issue, theres an nice code snippet in gpu gems, 3 maybe that takes care of the rough edges.
The sample code is excellent as an example... but, some things I noticed
Creating the light geometry each time the light changes isn't neccessary, rescale a unit mesh is better. Also an Ico sphere makes a nice point light
depth and ambient first pass. If you want screen space ambient occulsion (and who doesn't) then it should be a depth only pass, do the lighting then the ambient, these also the issue of things like fog which could easily be combined so the last pass might be lighting + SSAO + FOG, in my case I have those and atmosphere scattering, but really anything that isn't a screen based effect.
putting viewPos into the Gbuffer texture would have been a good idea imo rather than project the depth using the camera corner ray
something I really like in shaders, is this kind of thing
this way you can pack and unpack things like surface diffuse color and surface specular color you really don't need float4 for that, also you can move params around and add it them without changing much code.
DS is great you can have any number of lights, change shadowing, lighting, its all component based and you have all the data you need for post processes, its a brilliant system, why anyone would use forward rendering in his day and age is beyond me. Plus if you want a post render effect like depth of field, you need the depth, if you want SSAO you need viewPos, so for all that simplicity and flexability what does the GBuffer cost you?
Imo it doesn't matter that ogre is setup to be a forward render, it doesn't really make any difference as far as I can see.
The sample code is excellent as an example... but, some things I noticed
Creating the light geometry each time the light changes isn't neccessary, rescale a unit mesh is better. Also an Ico sphere makes a nice point light
depth and ambient first pass. If you want screen space ambient occulsion (and who doesn't) then it should be a depth only pass, do the lighting then the ambient, these also the issue of things like fog which could easily be combined so the last pass might be lighting + SSAO + FOG, in my case I have those and atmosphere scattering, but really anything that isn't a screen based effect.
putting viewPos into the Gbuffer texture would have been a good idea imo rather than project the depth using the camera corner ray
something I really like in shaders, is this kind of thing
Code: Select all
struct DS_PixelOutput
{
float4 mrt_0 : COLOR0;
float4 mrt_1 : COLOR1;
float4 mrt_2 : COLOR2;
float4 mrt_3 : COLOR3;
};
void DS_SetSurfaceDiffuseColour(inout DS_PixelOutput frag, in float4 surface_diffuse_colour)
{
frag.mrt_3.xy = PackFloat16bit2(surface_diffuse_colour);
}
half4 DS_GetSurfaceDiffuseColour(float2 coord)
{
return UnPackFloat16bit2( tex2D(MRT_Sampler_3, coord).xy );
}
DS is great you can have any number of lights, change shadowing, lighting, its all component based and you have all the data you need for post processes, its a brilliant system, why anyone would use forward rendering in his day and age is beyond me. Plus if you want a post render effect like depth of field, you need the depth, if you want SSAO you need viewPos, so for all that simplicity and flexability what does the GBuffer cost you?
Imo it doesn't matter that ogre is setup to be a forward render, it doesn't really make any difference as far as I can see.
-
- Gnoblar
- Posts: 4
- Joined: Fri Aug 30, 2013 4:42 pm
Re: Features for deferred shading
@r3v3r: what did I say precisely that you disagreed with? You have not contradicted my interpretation of deferred shading.
Edit: 'light transport phenomena' is meant as an example, and I don't know why the hell I wrote 'software depth buffer'
Edit: 'light transport phenomena' is meant as an example, and I don't know why the hell I wrote 'software depth buffer'