Intersection testing in large worlds

[craig.biggs_]

I have a question with regards to intersection testing in large worlds. Unigine uses a streaming model to stream data in and out for rendering but in the testing I've done I've found that you can perform your intersection tests ie engine.world.getIntersection regardless of the Player location - presumably you have a different representation of your physical entities than you do for your renderable entites. Am I correct here?

 

This leads to my main question - since we will be supporting rather large worlds when your next SDK release is out (500km x 2km for example), I'm wondering how Unigine handles this in regards to its intersection testing. Presuming that you do have a different representation for intersection testing, are all of these entities loaded in memory at all times, or do you have some sort of smart caching and if not is there much of a memory hit/degradation of performance on intersection tests for large worlds? We haven't generated content of this scale for Unigine yet hence my question.

[ulf.schroeter]

There are 2 main aspects for large world management:

 

* Increased coordinate precision

* Zone-based runtime background node file streaming for unlimited worlds

 

First aspect will be handled by UNIGINE with upcoming SDK update. The second aspect is - up to my knowledge - still open. UNIGINE already supports streaming texture and mesh resources (Still there are some problems).

 

Nevertheless all world nodes (including their physics body representations) still have to be loaded for the whole world at startup. For really large/complex worlds this is for sure unfeasible, so UNIGINE will require some kind of background node file streaming capability where only node clusters within a certain radius alround player will be kept in memory (and also would take part in intersection testing)

 

Hopefully they will provide such functionallity quite soon.

[manguste]

When intersection testing is performed, necessary nodes are loaded into the memory by the engine. That is why correct results are returned.

[manguste]

UPD. The way meshes are loaded on the startup depends on the render_manager_load_meshes console variable.

• If set to 1, all data on meshes, including bounding volume info, their vertices, triangles will be loaded at once.
  
• If set to 0 (by default), only bounding volumes info will be loaded (without any additional data). According to it, meshes are loaded only on demand:
  
  • if they are seen in the viewport
    
  • if intersection testing is to be preformed
    
  • if it participates in collision within physics distance
    

  In all other cases meshes are not loaded.

 

is there much of a memory hit/degradation of performance on intersection tests for large worlds?

As intersection is performed for further distance if compared to the single precision one, some performance degradation is imminent. But if you move the intersection point closer to the camera, there should be difference.

[ulf.schroeter]

meshes are loaded only on demand:

• ...
  
• if intersection testing is to be preformed
  
• ...
  

 

Hi manguste, will this be a blocking load operation causing render stalls or will intersection testing just trigger asynchronous mesh load (like when mesh gets visible in viewport) ? I would expect first variant which might be problematic.

[manguste]

Alas, would be a stall. Streaming is planned to be refactored at some time in the future; not this year, though.

[ulf.schroeter]

Streaming is planned to be refactored at some time in the future; not this year, though.

 

This is very bad news as this renders double precision support nearly useless for now. Large worlds requiring double support will ALWAYS require flawless streaming...