Features for next update


photo

Recommended Posts

  • Replies 72
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Cross-GUI interface to work with internal and external widgets (Unigine::Widgets). Unigine::Widgets::Graph class for flow-graphs. Scripts which are created in the flow-graph style (Unigine::Schemer

The editor on steroids.

Fully functional Terrain streaming and no lags on grass/clutter over-terrain generation.

Posted Images

as in the C# keyword using?

alias in D (which I am a bit more familiar with)

Link to post
  • 2 weeks later...

  • Cross-GUI interface to work with internal and external widgets (Unigine::Widgets). Unigine::Widgets::Graph class for flow-graphs.
  • Scripts which are created in the flow-graph style (Unigine::Schemer). There is no performance difference in compare with handwriting code.
  • Animation system which is based on Schemer (Unigine::Skinner). Replacement of current animation system with huge performance improvement.

This systems are written on UnigineScript and demonstrate upcoming editor functionality.

00000.jpg

00001.jpg

00002.jpg

00003.jpg

00004.jpg

00006.jpg

00007.jpg

00008.jpg

00009.jpg

  • Like 1
Link to post

Exceptional work, you must be very busy… Looks brilliant and we can’t wait for the release

Link to post
  • 1 month later...

Network file system server and plugin for mobile devices. Data folder can be placed on host PC and mobile device able to download all content via network.

Link to post

Cool!

Can't wait to see the final release ;).

Link to post
  • 1 month later...

Special objects (ObjectMeshCluster and ObjectMeshClutter) for rendering heap of instanced meshes. The performance boost in comaprison with ordinary objects is 3-4x.

00001.png

00002.png

Link to post

Special objects (ObjectMeshCluster and ObjectMeshClutter) for rendering heap of instanced meshes. The performance boost in comaprison with ordinary objects is 3-4x.

Sounds awesome! Are .node objects supported within such clutter/clusters? What is the difference with regular clusters and why do we need old ones?

Link to post

WorldCluster and WorldClutter places arbitrary nodes. ObjectMeshCluster and ObjectMeshClutter replicates theirs loaded mesh on multiple positions.

Link to post

Then I have a question, if my scene have multiple objects(Example: I have about 20 objects, each object have 100-1000 instance), each objects has many instance, so should I use ObjectClusters to replicates each objects' instance or use one or two WorldCluster to manage all these different instance objects?

 

 

Which way will give the best performance?

 

It seems the ObjectCluster/Clutter is a precondition to the vegitation system.

Link to post

ObjectMeshCluster is much effective than WorldCluster. The performance of ObjectMeshCluster with single instance is equivalent to performance of single ObjectMesh. But in case of ObjectMeshCluster we will have all instances for free. ObjectMeshCluster performs effective culling of inside. Multiple ObjectMeshClusters with multiple instances is a best way to render repeatedly geometry.

Attached screens are taken on Intel Core i3 (Sandy Bridge) with GeForce GTX 580. The rendered primitive is a box constructed from 24 vertices and 12 triangles.

00001.png

00002.png

00003.png

00004.png

00005.png

00006.png

Link to post

What is the possible practical application for such features?

Link to post

The whole world with a huge number of objects can be created by using this two objects. ObjectMeshClutter is ideal for trees, stones and clutter objects. ObjectMeshCluster is ideal for multiple manually placed objects.

Link to post

Looks great! However I'm little concerned about using multiple clusters for multiple meshes, but I'm sure I can live with it.

 

 

What is the possible practical application for such features?

outdoor rendering require a lot of stones, bushes and trees scattered over the surface. Right now we have to limit their visibility and poly count to have acceptable fps rate.

Link to post

Why not to join all stones into a few static meshes? That will reduce number of objects in the scene.

Link to post

Because this is both memory intensive and also greatly reduces engine culling efficiency (static mesh with e.g. 1000 baked instances will be drawn even if just 1 stone is within view frustum).

Link to post
  • 8 months later...

No ambient and light occlusion:

noao.jpg

Updated ambient and light occlusion:

aolo.jpg

Link to post

Because this is both memory intensive and also greatly reduces engine culling efficiency (static mesh with e.g. 1000 baked instances will be drawn even if just 1 stone is within view frustum).

 

Yes. Anyway there are various approaches, how to solve this. Analyze scene and make some joining manually to benefit from both frustum culling and instancing. I consider this as last stage of scene building.

Also there is even possibility to do some automatic joining on the fly (joining meshes within view frustum), but there are some technological limits.

Link to post
  • 6 months later...

Fully functional Terrain streaming and no lags on grass/clutter over-terrain generation.

  • Like 1
Link to post

Fully functional Terrain streaming.

what is the key difference to current terrain streaming ? Addition of coarse level streaming (as other parts already support streaming based on my understanding) ? Some details would be great
Link to post

Current terrain implementation doesn't use background data loading. There are a lot of rendering stalls because of that.

Right now I can smoothly flight with 1km/s speed across a set of 16x16 terrains with a total height map size is 65536x65536 (256x256km).

The diffuse/normal/mask texture dimension is 131072x131072. The whole terrain dataset is 55GB in 200K files.

And of course high density grass/clutter objects across the whole area are presented.

Link to post