Back to General and Gameplay Programming

Efficient way to check which lights belong to which meshes?

NULL NULL · 2015-03-25T21:12:07

Yo, this is Solid here. I'm in a bit of a bind here. I was wondering what method to people generally use to determine which dynamic lights can affect which objects? For instance, I have a lighting shader that supports only up to 8 lights. I have over 20 dynamic lights in my scene, and over a hundred objects with only around 6-7 lights within range of them. I want the objects to know which lights affect them, and the lights to know which objects it will use to generate shadow maps. How do I go about determining which lights belong to which objects, in an efficient way? I already wrote a collision test that loops through every light and then through every mesh to check for collision with sphere vs sphere tests, and it works just fine, except it is rather slow, and takes up around 3-4 ms on my laptop, and 0.8 - 1.0 ms on my computer. It is a tad slow, and I want to speed it up some more. Also I use frustum culling to cull lights that are out of view. I came up with the idea of using an octree, to separate all the static objects on the first frame, and then each frame add and remove the dynamic objects/lights. Each node has an std::vector for storing objects as well as their rendering/lighting/physics/ components, if it has one. Then after, I am planning to do a sweep and prune for every separate node in the quadtree on the x and z axis, and then store the light vs object collision pairs in an std::vector. And then last but not least, I can just iterate through every collision pair and push the meshes that collide into an std::vector inside of the lighting component it collides with for shadow map rendering, as well as add data from the lighting component into the mesh component so that it knows which light it gets affected by. Although this may sound like a good idea, I fear that it might actually be slower. I mean, I am using a lot of std::vectors, and creating them every frame in the octree (for dynamic objects), and constantly filling/flushing vectors in the lighting components. I was wondering if there is a more efficient method, or is this as good as it can get? What other methods are other people using for this sort of thing? I'm guessing I may have to just tone down the number of dynamic lights ultimately, since they are very expensive in general. I can do the collision test only once for static lights. What are your recommendations?

General and Gameplay Programming Programming

Started by SolDirix March 23, 2015 03:53 PM

13 comments, last by Avilius 9 years ago

SolDirix

721

Author

March 23, 2015 10:35 PM

But those 6frustum culling passes per light should be very fast bebecause they should only operate for subset of data. Assuming that you do range check before.

Ah, correct.

I did another test with the release version and I got an average of 0.1ms :s! I don't know why it's so low now (I guess I had a game running in the background or some debugging file idk). Still a bit high though. I'm gonna take some time to look into what I am doing wrong.

Quicky algorithm that I would try.

1. Frustum cull visible lights.

2. Sort lights by radius.

3. Frustum cull objects but add biggest radius of visible lights for every object.

4. For each visible light loop over object list from pass 3 and do range check. For each face frustum cull objects that are inside the range.

Hmm, that seems like a good idea. I will try that actually. I may have to do two frustum culls though. One with the radius and one without. So that way objects outside of players view don't get rendered. I may also need to make some dynamic lights smaller for this to be more efficient.

View my game dev blog here!

Armagedon

1,239

March 24, 2015 11:19 AM

Also you could cache list of lights affecting each mesh and update only if given mesh moves or light moves.

bioglaze

1,637

March 24, 2015 02:55 PM

You could use a Forward+ renderer and cull lights in a compute shader to get a list of lights for each screen-space tile.

Aether3D Game Engine: https://github.com/bioglaze/aether3d

Blog: http://twiren.kapsi.fi/blog.html

Control

SolDirix

721

Author

March 24, 2015 04:11 PM

You could use a Forward+ renderer and cull lights in a compute shader to get a list of lights for each screen-space tile.

Sounds good, but i'm planning to support openGL 3.3, which doesn't support compute shaders.

Either way, I found the reason it is acting so slow. I'm iterating over an std::vector<boost::weak_ptr<RenderingComponent>>, and locking each one for every light for checking for collision detection. I'm gonna have to move away from shared ptrs since they are too slow, however I am having difficulty finding a way to iterate through all rendering components without knowing if they are dead or not.

I may try using a memory pool of rendering component ptrs and update every frame, checking each game object to see if it has a rendering component in it's component map, but idk, probs won't be as slow as locking weak ptrs, but still sounds slow.. I didn't think this issue would pop up again.

View my game dev blog here!

Avilius

711

March 25, 2015 09:12 PM

...Don't do that. If you're going to make a memory pool, store the actual structures themselves in the pool, not pointers to them. If not, you won't see much of an improvement (or any, really). Smart pointer's aren't really faster or slower than normal pointers. The problem is that you're thrashing your cache, which really kills performance especially in portions of code that are performance-critical. Checks like this do not belong in any low level subsystem, much less a renderer. This belongs in a scene manager. The renderer has no idea what a game object is. It should just take in a structure similar to this:


struct render_item_t
{
    uint16_t vertex_buffer_id;
    uint16_t index_buffer_id;
    uint16_t material_id;
    uint16_t offset; // Offset in vertex buffer
    uint16_t size;   // Size
};

And spit out pixel values to be sent to the monitor.

The scene manager decides what is drawn and how, then constructs the appropriate command buffer for the renderer to consume.

Efficient way to check which lights belong to which meshes?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Efficient way to check which lights belong to which meshes?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines