Memory usage of multiple instances of identical geometry

[AussieKSU]

I would like to add many (10k-100k) instances of a particular geometry into the scene. For simplicity sake, we can consider the geometry a cylinder. I have used (Jerome's excellent) Solid Particle System to solve this problem. We will see very good performance with respect to FPS simply using add shape ie. addShape(cylinderMesh, 100000). 

HOWEVER

Solid Particle Systems will still duplicate the geometry needed for the cylinder. We will see the geometry duplicated x100000 in the resulting mesh, causing the brower to store all the (transformed) vertexes. Is there a solution which can "reuse" the geometry, and keep the memory footprint low for my scene (shaders perhaps)? Is there Something that will set the vertex attributes to the GPU once, and then provide a set of transformations? I know display lists are not supported in OpenGL ES, and maybe this is the killer for my desired behavior?

[GameMonetize]

Seems like you need to use instances: They share the geometry and provide a set of transform : http://doc.babylonjs.com/tutorials/how_to_use_instances

[jerome]

Yep you're right : in the SPS the geometry of each particle is stored in the global SPS mesh geometry (don't forget you can change each particle geometry on the fly though .. and that each particle can be built from a different shape/geometry).

This means a float triplet per particle vertex + a float triplet per vertex normal. You can easily deduce the required memory.

If I'm not wrong, as the instances share the same geometry, a single set of vertices/normals is enough for all. In the other side, each instance needs its own world matrix, so an array of 16 floats per instance, whereas the SPS manages only one global world matrix.

Just measure and compare both for your real concrete case to check what fits the best to your need.

[AussieKSU]

I had a notion that instances may be recommended. I have two observations about instances (happy to provide playgrounds if desired)

1. The memory footprint of instances is not trivial. Even creating 20,000 instances of a very simply geometry, I see the memory of the browser climb to ~150Mb (Chrome). It seems that instances still need some memory in their backbone to exist. Each instance, of course is allowed its own matrix, but this should account for 1.22Mb (if my math is correct).

2) The FPS of many instances seems to decline sharply. Perhaps this has to do with the draw calls involved with instances (a separate call for each, perhaps?). Instances may be a great solution in other cases (perhaps with meshes with very complex geometry), but it seems the quantity of instances with respect to FPS performance seems to be a limiting factor for me.

[JCPalmer]

There is not currently any free lunch.  I cannot speak to #1, could be a leak.  Not many people have pushed instances to such levels.  Also in addition to the 16 float32's, there are 3 vectors (location, rotation, scale) each that have 3 number64-bit.

#2 is not a matter of draw calls but of the javascript overhead of calculating 20,000 matrices, or at least checking it needs to be done .  Scenes with this many meshes are DOA in my opinion, due to overhead.

[jerome]

I agree.

100K objects visible in the same time are really a huge number... only to display them on the screen considering the number of pixels. Do you really need 100K visible objects simultaneously ?

 

[AussieKSU]

In my application, it is very possible for 100k objects to be in the frustum at a given time. I have it in mind to implement some fixed frame rate logic which will order the meshes based on their projected size on the screen (done via a web worker, similar to Ranaan's collision solution), and render only as many as time permits each Render loop (while the camera is not moving, this time constraint is relaxed). This addressees the FPS constraint of any of the above solutions (instances, SPS or simply merged meshes). This solution is a bit lower priority since SPS performs very well indeed. However, this does not address the memory pressure - hence my thermo nuclear solution below:

I have in mind to implement some frustum logic that will dispose, as needed, meshes that fall outside the view frustum. Furthermore, for objects in the view frustum which are not yet loaded (or have been disposed) a server call will be made to (re)acquire the data. This is a complex but doable solution. However, before I use the thermo nuclear option, since many of the 100k objects use identical geometry, I want to make sure I am not missing some good fps AND memory solution. Vertex shaders or something along those lines?

[jerome]

I understand your approach and probably some dedicated vertex shader would help in your case.

What I initially meant with my question about the 100K visible objects was :

- 100K objects can be in the frustum,ok ...but 100K is big number of things to be drawn on the actual screen area. Even if they are all in the frustum, plenty of them won't finally be visible to the user, because they are hidden by others unless they are all very little (or very far in the distance, so projected as little). Perhaps you might not really need to manage 100K visible objects and you might recycle the invisible/hidden ones. 

- Moreover the user eyes/brain can hardly makes the difference between huge numbers, especially when there's no mean to compare (another scene besides with another amount of objects to compare to). But the CPU/GPU (especially the CPU with the js monothread) can really feel the difference between 20K and 100K iterations !

So here again, maybe is there a way to fake the real number of visible objects ... pretend it's 100K whereas it's only 30K in your array and  you actually draw only 15K in the frustum. 

Just as a side idea, maybe a dynamic texture depicting very simply plenty of little "things" in the distance (blurred shapes, points, etc) and displayed in the background could fake at reduced cost the thousands of distant not computed instances meanwhile.