for all r in renderables {
lights = find_all_lights_touching_r
for all l in lights {
render_r_with_l
}
}
Instancing and Lighting?
Author
Hi,
instancing is an interesting topic nowadays. But now that I actually want to implement it, I wonder how to mix it with lighting.
In a typical forward rendering pipeline, lighting works like this:
This is very correct, and that's another reason why deferred shading is so handy. You can instance all your geometry without having to think about the lighting fase yet. This works great for small object, trees, ... I asked this same question to ATI and the only thing they had to say to this was to devide the world into patches and instance locally only, and all lights which influence this patch will be added to a list processed by the shader. Not a handy solution if you ask me.
This the reason why I still use a deferred rendering for my outdoor environments. While I actually want to get rid of deferred shading because of the hardware problems I have with nVidia (nVidia is very slow when rendering to 4 floating point render targets on a big resolution compared to ATI - our outdoor environments run almost 70% faster on ATI than on nVidia). How else can you render an outdoor nightscene with more than 50 dynamic lights .. ?
Regards,
Kenzo
This the reason why I still use a deferred rendering for my outdoor environments. While I actually want to get rid of deferred shading because of the hardware problems I have with nVidia (nVidia is very slow when rendering to 4 floating point render targets on a big resolution compared to ATI - our outdoor environments run almost 70% faster on ATI than on nVidia). How else can you render an outdoor nightscene with more than 50 dynamic lights .. ?
Regards,
Kenzo
Quote:How else can you render an outdoor nightscene with more than 50 dynamic lights .. ?Use a hybrid renderer :-) ... normals layed out in screenspace like in deferred rendering.
Keep in mind that, if you've got a bunch of objects or characters on-screen, most of them aren't going to need full-fidelity rendering. Using ambient plus one dual-hemisphere light per object will probably be plenty for most instances.
Quote:
Use a hybrid renderer :-) ... normals layed out in screenspace like in deferred rendering
if you this I presume you also use MRTs to render and you loose hardware AA anyway right?
Quote:
Keep in mind that, if you've got a bunch of objects or characters on-screen, most of them aren't going to need full-fidelity rendering. Using ambient plus one dual-hemisphere light per object will probably be plenty for most instances.
true, but rendering the terrain 50 times is also no good solution :) (for the terrain smple lighting won't be enough). Something in between has to be found and it's just a harder to do because you to take care of more things then default deferred rendering. But in the end, if you have a good working system, it will probably be faster.
Quote:Original post by GuoshimaQuote:
Keep in mind that, if you've got a bunch of objects or characters on-screen, most of them aren't going to need full-fidelity rendering. Using ambient plus one dual-hemisphere light per object will probably be plenty for most instances.
true, but rendering the terrain 50 times is also no good solution :) (for the terrain smple lighting won't be enough). Something in between has to be found and it's just a harder to do because you to take care of more things then default deferred rendering. But in the end, if you have a good working system, it will probably be faster.
Yes, rendering the terrain 50 times would be a bad idea.
I personally don't like the generic deferred approach because it constrains the interaction between lights and surfaces.
You could do also something intermediate for terrain lighting, like rendering to a light buffer, and then apply the light buffer once when rendering the terrain.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
