[SOLVED] dynamicly generate object and add to world node list using muti-thread

[chao.zhang]

Hello everyone.

Now we are implementing a Globe GIS system based on Unigine.
The hole Globe earth are constructed with a lot of tile meshes, which are
dynamically generated according to the distance between the camera position and tile meshes' center.

At first, we write the tile generating algorithms in the main loop in main thread, but this cause a
problem, the main thread would get stucked because the tile generating algorithms consuming a lot of time.

so we start another worker thread to dynamically generate new objects to add to the render list,

would this be safe ? since we always came into crashs in running.

Thanks in advance.

[ulf.schroeter]

If you are talking about a C++ worker thread that accesses the engine at the same time as the main thread than this is NOT safe. It is only safe to call the engine from one thread instance.

 

Therefore you should better split your work for tile generation into some incremental implementation meaning calculating the required globe tiles vbased on viewer position in the main thread, storing this "jobs" in a dynamic queue for doing as much non-render-related work in the background thread and return the results back to the main thread via some result queue. The main thread than picks a limited amount of results per frame from the queue and can call safely render-related engine functions e.g. mesh generation. With such a pattern you could avoid unsafe multi-threaded access to the engine and render stalls.

[chao.zhang]

Thanks Ulf, I wonder whether operation like

new ObjectMeshDynamic() is thread safe to be called in another thread?

 

suppose during one main loop in main thread, I have 200 new tiles to create, if all the mesh creation

must in main thread, this will cause the main thread stucked for several second, If I have much more

new tiles to create, this time would be more.

 

Are there a solution for this?

 

Thanks in advance.

[ulf.schroeter]

there a solution for this?

 

Yes, rethink your approach !

 

Simple fact (of course I am guessing a little bit, as I don't know your exact requirements/implementation): you will not be able to create such large amounts of resources per frame without stalling the render thread. There only 2 general approaches to avoid this:

1. Pre-calulate/allocate resources and simply enable/disable them during runtime as required
   
2. spread your total work about multiple frame
   

[chao.zhang]

Thanks for your suggestion Ulf.

 

for 1. Pre-calulate/allocate resources and simply enable/disable them during runtime as required

 

This is probably not possible. When LOD get to the next level, one tile would split into four tile meshes.

Let us suppose the total LOD level is 18 (This is very common for GIS, such as googleearth). The total

mesh object number would be 4^18. I don't think it is possible to create so much objects in advance.

 

for 2. Spread your total work about multiple frame

 

As the new added tiles are all generated on the fly according to the movement of camera, it is not very

feasible to spread into muliple frame.

[ulf.schroeter]

As the new added tiles are all generated on the fly according to the movement of camera, it is not very feasible to spread into muliple frame.

 

Only a very small part of your tile quadtree changes during camera movement between frames. Some lower-level tiles will have to be split, some higher-level tiles can be replaced by existing lower-level tile. Only these incremental changes have to be handled. Put these changes into a work queue and create required new meshes spread over multiple frames. Newly required textures files assigned via material instances will be loaded by UNIGINE anyway in the background with several frames delay. Normally during this time periode lower-resolution texture of low-level tile(s) can be used as lower quality substitute (same approach in Google Earth and Maps)