UNIGINE Sim

[ulf.schroeter]

The new UNIGINE Sim homepage gives an excellent overview on dedicated simulation features. Nevertheless at the moment it is hard to find

 

UNIGINE Sim reference should be put on central UNIGINE homepage (www.ungine.com) or at least into Engine subsection.

[binstream]

Ulf, it's still in the work - showcase and news sections, Chinese localization are to be introduced next week.

 

Until then we don't promote the new website heavily.

[ulf.schroeter]

Ah ok, good news, if you're still working on it maybe you can include the following:

 

One important available UNIGINE feature missing in the "Build for Simulation and VR" subsection is the frame time management feature (e.g. time budgets for streaming, texture and mesh preparation per frame). This is an essential feature for customer simulations having to ensure stable fixed frame rendering time (30/60Hz).

 

BTW, the current implementation still seems to be suboptimal as it only supports individual absolute time budgets per background task. Depending on the settings and the actual per-frame workload this might cause waste or overload of current available frame time budget for these background tasks.

 

Instead the frame time budget managment might be implemented more dynamically. Starting point should always be the targeted constant frame time (e.g. 33ms for 30Hz/ 16.6ms for 60Hz). As the GPU always renders much longer than it takes to submit all draw/update calls during the CPU-side update phase there has to be an upper time limit for this "update time period".

 

This update phase defines the total available time buget for CPU-side operations per frame (e.g. 20ms for 30Hz/10ms for 60Hz) which has to be enforced by the engine. This maximum budget should be user-definable e.g. engine.setUpdateBudget( float time in seconds). This update time is logically composed of a "submit time period" and a "background task time period".

 

The "submit time period" is the time required for submitting all scene related draw calls which cannot really be changed as this is defined by the visible scene. This mandatory "submit time period" might varry from frame to frame depending on visible scene parts will dynamically reduce the remaining "background task time period". In worst case it might even exceed the complete "update time period"

 

As the "submit time period" is dynamic while the "update time period" is fixed the time budget for all additional "backgroud task" operations should be limited dynamicall on a frame-by-frame basis to

 

available background task time = max( update time period - submit time period, 0 )

 

This remaining dynamic background task frame time budget should than be used as upper limit for ALL additional background operations within the render thread. This seems to be different to the current approach of defining fixed time budgets for individual background tasks within the render thread.

 

Of course the key problem for all frame time management is that a CPU-side time limitation does not necessary mean that also the corresponding asynchronous GPU-side operations will be finished before exceeding the targeted maximun frame time (e.g 33.3/6.6ms), but I would assume this cannot be changed easily by principle.

 

But maybe frustrum will find the best-possible solution ;)

[steve3d]

ha, just looked the new page for simulation. the Chinese part is not finished yet :)

[binstream]

Chinese translation is ready - feedback is appreciated: http://ch.sim.unigine.com