Jump to content
  • Advertisement
Sign in to follow this  
dv

Instancing and Lighting?

This topic is 4238 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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:
for all r in renderables {
  lights = find_all_lights_touching_r
  for all l in lights {
    render_r_with_l
  }
}
This renders one light per pass. Of course, r could be rendered with more lights at the same time, but this is simpler for this posting. Now how should instancing fit in this? Enumerate all lights touching all instances and send this list to the object *once* (maybe as lookup in a vertex buffer), or determine it per-instance? What gives better results in the end? Also, how do shadows fit in this best? BTW, I am amazed at how little material is available about the important topic of determining lit renderables. It is actually not trivial, especially with shadows.

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Guoshima
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.


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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!