Jump to content

Huge frame rate drop when enabling projector light


photo

Recommended Posts

Hi,

 

Currently we are implementing our headlights for our rail simulator using projector lights and have found a problem. To turn lights on and off we enable/disable the LightProj node that is attached to our vehicle node (its actually attached via a NodeReference but in my testing this doesn't seem to make any difference) and we have a Player attached to the vehicle. When I enable the LightProj node to turn the headlights on, I see a huge drop in frame rate (and the profiler shows a massive spike). So I have a couple of questions 1) is this to be expected 2) is there a way to work around this eg by keeping the node enabled at all times but modifying some of the LightProj parameters such that its not having an effect on the scene.

I'm currently using the Nov 2012 SDK, if it is a known problem that has been fixed since then, please let me know.

 

thanks

 

Craig

Link to comment

Does this only happen on first time activation or alwaysfirst (even when toggled quickly) ? If first might be caused by initial mask texture uploading

Link to comment

Hi Craig,

 

A screenshot of your profiler would be useful, 2 x screenshots of the profiler statistics before lights enabled and after (use the 2nd profiler toggle statistics)

 

My initial thoughts are that the light and shadow distances are set to infinite (default) and given the size of your world this would be (if 2 headlights) probably tripling the RTris as each new light causes a new pass to be rendered for all affected surfaces.

 

Try setting the distance to something reasonable on both the light distance and the shadow distance.

 

Will light masks help? (possibly not in your case).

 

 enter manguste from stage left: "try deferred lighting" ;)

 

Keep us posted.

Link to comment

Ulf,

 

Thanks for your prompting, I woke up this morning and realised I left this detail out. Yes the frame rate drop is only initial and after the initial drop, the total time spent in Unigine per second increases maybe 10% on what it was before but that's not unexpected. Additionally, this problem doesn't happen every time but if you disable then leave it for a while, then enable, the frame rate drop/profiler spike happens every time (probably not surprising).

 

I've tried modifying the light masks rather than enabling disabling and the same thing happens. "Force deferred lighting" doesn't make any difference and we've currently got our Visible distance and our Shadow distance set to 1000.

 

I've spoken to our lead artist who tried it on a world/different terrain and apparently the performance drops but rather than seeing a big frame rate drop and then smooth solid performance, he saw a more consistent drop from 60fps to 30fps consistently.

 

I'll do some more profiling today and keep you posted.

Link to comment

Some further information that may be of assistance - if i disable all of the terrain tiles except for the current one with the light shining on it the problem does not occur.

However our tiles are 8193 x 8193 large and as Craig stated our rendering distance for the light is only 1000 for both lighting and shadows.

 

If a slowly enable terrain tiles one at a time, the problem gets worse for each tile i enable.

 

it is acting as if lighting is being calculated on all the terrains even though that does not seem possible with our distance settings?

 

With shadows turned off the problem does not occur at all.

 

The same issue will occur if testing an Omni Light.

Link to comment

I Have done some further testing and found this problem goes away if i move the light to 0,0,20 in the world.  However if i move the light even slightly away, say to 100, 100, 20 then the enable/disable pause and frame rate drop returns.

Link to comment

Can you provide a sample?

This could be harder to provide a test case for as it seems to only happen on worlds with many terrain tiles and file size then obviously becomes an issue - however i will see what i an do

Link to comment

Yes the frame rate drop is only initial and after the initial drop, the total time spent in Unigine per second increases maybe 10% on what it was before but that's not unexpected. Additionally, this problem doesn't happen every time but if you disable then leave it for a while, then enable, the frame rate drop/profiler spike happens every time (probably not surprising).

 

@UNIGINE: Just guessing here based on some previous render stall problems with ObjectMesh, but might be related to some synchronous texture loading issue for project light (maybe mask texture?). In the ObjectMesh case there was some forced synchronouse texture loading operation in the render loop causing frame stall. 

 

As textures will be unloaded automatically after some time (128 frames ?) when not used during rendering, this could also explain, why the frame drop re-appears after some time when light had been turned off, but not on fast toggeling of light enable state (as in this case the texture hasn't been unloaded)

 

Of course just an idea based on some weak sympthoms, but maybe helpful as a starting point (though I don't know if terrain has any influence on this problem)

Link to comment

Thanks for input Ulf - i still do not understand why it behaves differently if the light is at 0,0,0 area (the stall does not occur)

Link to comment

yep, that's strange, I missed that previous post...as next testing step you could reduce your distance setting from 1000 to e.g 50 and check if this avoids/reduces the frame drop. If there is no difference, than I would still think its texture-related, so next step for testing could be running the same database with downscaled textures (e.g. 2k instead of 8k)...sometimes also the driver can cause such render stalls, have you tried to reproduce this effect with another render API (e.g. changing from Windows DX11 -> 9 / OpenGL ) ? 

 

BTW looking at the screenshots: the only really significant difference is 48 MB memory increase after light enable. Do you have an idea what caused this increase ?

 

Its always "fun" to track down such kind of problems :wacko:

Link to comment
  • 2 weeks later...

Some further information on this - unfortunately an example scene is not feasable since our content to replicate is around 25gb

-Turning off shadows makes the issue dissapear (Shadows are set to 1000 for distance, but have tried as low as 500)

-Our world consists of many Layers each with the following child nodes: 1 terrain tile, 1 Trees (mesh Cluster node), 1 Bush (mesh cluster node), 1 Grass node

 

I have found that disabling all of these except the terrains for our world makes the problem go away.

Leaving terrain enabled, and disabling  the others  in every possible combination, but leaving even 1 enabled and the problem still occurs.

 

So it seems it is the mesh clusters and the grass that are related to the issue, but not the terrain in any way.

Link to comment

The masks i changed were the Clutter and grass masks (they use the same mask file per tile)

The size is 1024 x 1024 for each mask file - Using less does not give the required accuracy

Link to comment
  • 2 months later...

Hi, I've done some testing of this using the April 2013 SDK, and this situation where the enabling of a projector light a long way from the origin has certainly improved. However, there is still a performance drop the first time a projector light is enabled. I was wondering if there are any measures that can be taken to improve this performance drop eg cache files or something similar.

Link to comment
  • 10 months later...
×
×
  • Create New...