Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Solid_Spy

Member Since 26 Nov 2012
Offline Last Active Yesterday, 07:44 PM

Posts I've Made

In Topic: Efficient way to check which lights belong to which meshes?

24 March 2015 - 10:11 AM

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.


In Topic: Efficient way to check which lights belong to which meshes?

23 March 2015 - 04: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.


In Topic: Efficient way to check which lights belong to which meshes?

23 March 2015 - 04:11 PM

Twenty lights and a couple hundred objects? Brute force sphere-sphere testing should be nearly instant in this case. You're doing something wrong there.

I forgot to add, I am doing 6 frustum cullings per light since they are point lights that use shadow cube maps. This is only done for dynamic lights though.


In Topic: Efficient way to check which lights belong to which meshes?

23 March 2015 - 04:10 PM

 

No they can't. If you want to have finite bounding volume for light this also mean you need to modify falloff function to go zero when at max range. so shadows can't cast outside of light range.

 

edit: Assuming frustum vs bounding sphere culling.

 

Yes, that is what i'm doing. I did a test with a small bias of 0.1f offset and the lights shadows still appear just before the bias is breached. The frustum culling is working. Might I add that I am also checking for 6 frustum cullings around the point lights, to check which sides of the shadow maps get which meshes.


In Topic: How to limit FPS (without vsync)?

16 March 2015 - 05:10 AM

Thank you all for your help. I currently have it working without using vsync, using this:

while(profiler->fpsUnlimited * 1000.0 < 3.0)
{
    profiler->TimeStampStartAccumulate(PROFILER_TIMESTAMP_FPS_UNLIMITED);
    timeBeginPeriod(1);
    Sleep(1);
    timeEndPeriod(1);
    profiler->TimeStampEndAccumulate(PROFILER_TIMESTAMP_FPS_UNLIMITED);

    profiler->fpsUnlimited += profiler->timeStamps[PROFILER_TIMESTAMP_FPS_UNLIMITED];
}

However, I will also attempt to get this to work with vsync and try to fix the input lag issue.


PARTNERS