Hi, I read about deferred shading, an great technique for rendering MANY Lights (in fact about 50 should be possible). The problem is: We need to render many informations into single RTs. (That makes a whole bunch of Render calls neccessary)
It works the following way:
We render normal, position, diffuse color, specular power etc. in different and combine them in a single 2D pass to the final image. (Which allows us to have further more cheap soft-shadows, geometry based distortions etc.) However, there are two major problems:
First, the amount of memory needed (a map for spec power, spec strength, pos, normal, shadow etc) and we would have to do a single rendercall for everything (normal pos etc) each with a different target. My Question is now: is there any solution, to render informations into multiple targets(I don't think so) or to reuse the informations out of the first render call to optimize the second, third etc ones??
I guess this would be easier with DX 10 (Render to Volume tex)
I would be interested in your ideas..
has anyone done something like this??
greetz TGM
*Edit1* I was doing some "research" and was confronted with the word "frame buffer object" although I'm not jet sure, wether this is realy what I was looking for, I'm going to have a closer look on them...
*Edit2* ok, acordingto this article:
http://www.gamedev.net/reference/articl ... le2333.asp
It really looks like it would be possible to render into different RTs at one time... That would be such a great improvement to irrlicht!! I have to think about patching irrlicht... would be damned cool to have such stuff like diffuse, spec, position, depth, normal etc for post processing (DoF, and all that stuff, besides better control about the composition..)
*Edit3* should irrspintz maybe capable of doing this ?? I've to figure that out
Deferred Shading/rendering into multiple Targets
-
- Posts: 275
- Joined: Fri May 12, 2006 6:37 pm
- Location: Germany
sio2 released a demo for multiple render targets using irrSpintz, look at his demo website.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
MRT: multiple rendertargets are cool, since they allow you to do pass allot of information to processing effects with one geometry transform (which in some cases is very limiting since it wastes both cpu and gpu time). MRT's (shader model 3 ) require Frame buffer objects(shader model 2). Buffer objects are gpu memories that can be used for anything.
Having a complete lighting model in a deferred shader is not cool, it requires all your inputs to be the same resolution as that on your screen (for decent effects anyway), which wastes both filtrate and texture memory. Further more texture reads are wasted on things like a material texture(tells the deferred shader what algorithm is used to shade things). without a material texture for example all your game objects will be shaded in the same way(and hence unnatural and not artistic) unless you complicate things even more.
Alpha blending has to be dealt in a special depth testing shader, so alpha objects cant be shaded in the same way. And the speed will never be as fast as the default implementation.
However limited forms of deferred shading with normal forward rendering can be useful (im doing some experiments using both together for a cool effect). Doing a complete lighting model / specialized effects using deferred shading can complicate thing and wastes performance.
I havent tried MRT in dx(is it there?) but in opengl it is very simple (there are many slideshows on the web with code and explanations); google framebuffer objects opengl presentation.
Having a complete lighting model in a deferred shader is not cool, it requires all your inputs to be the same resolution as that on your screen (for decent effects anyway), which wastes both filtrate and texture memory. Further more texture reads are wasted on things like a material texture(tells the deferred shader what algorithm is used to shade things). without a material texture for example all your game objects will be shaded in the same way(and hence unnatural and not artistic) unless you complicate things even more.
Alpha blending has to be dealt in a special depth testing shader, so alpha objects cant be shaded in the same way. And the speed will never be as fast as the default implementation.
However limited forms of deferred shading with normal forward rendering can be useful (im doing some experiments using both together for a cool effect). Doing a complete lighting model / specialized effects using deferred shading can complicate thing and wastes performance.
I havent tried MRT in dx(is it there?) but in opengl it is very simple (there are many slideshows on the web with code and explanations); google framebuffer objects opengl presentation.
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
-
- Posts: 275
- Joined: Fri May 12, 2006 6:37 pm
- Location: Germany
Well, I would shade all materials the same way.. (pong with spec power/strength)
*Edit* ok I realised, what a bullshit I was talking... sry^^
there has to be reflective materials and stuff...
but it would be possible to render all the standard geometries (95% of all geometries I guess) In one pass, combining it with the Transparent / special stuff?? You could even use a Stencil buffer to mark objects that render their own lighting etc..
*Edit* ok I realised, what a bullshit I was talking... sry^^
there has to be reflective materials and stuff...
but it would be possible to render all the standard geometries (95% of all geometries I guess) In one pass, combining it with the Transparent / special stuff?? You could even use a Stencil buffer to mark objects that render their own lighting etc..
have you ever tried doing a lighting calculation for more than 5 lights in one pass? I think there is some advantage for many lights..And the speed will never be as fast as the default implementation.
For speed i was talking of alpha blending speed, as for stencil for material id's the only way you can read stencil in a pixel shader is by another texture read, for something that is constant over many fragments its a waste to keep reading from a texture.
The only speed increase is from fragments that are overwritten (the actual deferred shading code is actually slower and will eat away your texture bandwidth), bad sorting of fragments will be a situation where deferred shading wins but sorting things properly will minimize overdraw and hence normal shading will win.
one advantage of deferred shading is good batching, but that can also be done in normal shading although not as perfectly if you use more materials.
Most Gpu's now have massive ALU power but sadly texture memory speed is lagging, so its recoomended that texture read on new cards are kept low (opposite to older cards).
Another very annoying limitation is that all your material shaders have to be coded as one big shader which might cause instruction count problems (dynamic branching is not cheap especially if it controls the flow of large progam chunks as you cant do other instructions in parallel while you decide on the condition).
The only speed increase is from fragments that are overwritten (the actual deferred shading code is actually slower and will eat away your texture bandwidth), bad sorting of fragments will be a situation where deferred shading wins but sorting things properly will minimize overdraw and hence normal shading will win.
one advantage of deferred shading is good batching, but that can also be done in normal shading although not as perfectly if you use more materials.
Most Gpu's now have massive ALU power but sadly texture memory speed is lagging, so its recoomended that texture read on new cards are kept low (opposite to older cards).
Another very annoying limitation is that all your material shaders have to be coded as one big shader which might cause instruction count problems (dynamic branching is not cheap especially if it controls the flow of large progam chunks as you cant do other instructions in parallel while you decide on the condition).
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
-
- Posts: 275
- Joined: Fri May 12, 2006 6:37 pm
- Location: Germany
I didn't say its bad, in fact its very good for fogging, atmospheric scatter, very ambient lights, usually things that are very uniform across the screen. But yes practice is the best way to learn.
"Irrlicht is obese"
If you want modern rendering techniques learn how to make them or go to the engine next door =p
If you want modern rendering techniques learn how to make them or go to the engine next door =p
Gotta learn the hard way!
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net