Clones ... what's the skinny?

The simulation I hope to port to jME will feature fairly large numbers of fairly hi-poly model ships. I know that you are working on CLOD and such, but I wonder what features (or combinations of features) will best help me get the most ships into a virtual sea battle.



It is possible that a fair number of the ships in a battle will have the same basic model (sister ships), though components on board may differ (turrets in different orientation or damage state, etc). Would it be helpful to put a CloneNode for each distinct hull model shape into my root node, and have each ship be a clone of the model data stored in the CloneNode for its shipclass? Will this save memory and boost performance at run time, or simply reduce load time? Or have I misunderstood Clones?



Secondly, would the Clones be able to take separate advantage of CLOD, or does the variety of runtime geometries produced by CLOD make the advantages of Cloning disappear (as I suspect they might)?



FYI, jME did fairly well at putting 20 separate instances of a Model based on my 3286 (or twice that?) poly ship on screen. Frame rate seemed smooth, but I suspect the frame rate counter (copied from TestManyChildren, but employed in my test in a FixedLogicrateGame rather than a SimpleGame) was giving bogus data: it read highest when there were more polys in view than not!





tone

It is possible that a fair number of the ships in a battle will have the same basic model (sister ships), though components on board may differ (turrets in different orientation or damage state, etc). Would it be helpful to put a CloneNode for each distinct hull model shape into my root node, and have each ship be a clone of the model data stored in the CloneNode for its shipclass? Will this save memory and boost performance at run time, or simply reduce load time? Or have I misunderstood Clones?


Clones are beneficial in that they use the same geometry and are able to render it multiple times in various locations/orientations. So, the clone reference the same geometry in the CloneNode. This means, that any change made to the geometry will affect every clone. So, this great decreases memory load, load time (only loading geometry once), as well as rendering speed (vertex pointers loaded only one time).

However, this means you can't have clones with multiple ships with turrets in different directions. That is, the clones all look the same. While I like your idea of altering the same Geometry different for each clone, I don't know how we could go about doing that.

Any suggestions?

Secondly, would the Clones be able to take separate advantage of CLOD, or does the variety of runtime geometries produced by CLOD make the advantages of Cloning disappear (as I suspect they might)?


Because of the reasons above (sharing the same Geometry) CLOD wouldn't be used in conjunction with clone. It would be nice though, if a clone could adjust the common geometry for a particular level of detail. But again, I'm not sure how we'd do that.

FYI, jME did fairly well at putting 20 separate instances of a Model based on my 3286 (or twice that?) poly ship on screen. Frame rate seemed smooth, but I suspect the frame rate counter (copied from TestManyChildren, but employed in my test in a FixedLogicrateGame rather than a SimpleGame) was giving bogus data: it read highest when there were more polys in view than not!


Definately needs looking into. Thanks.

One thing to understand about clipping is that your description of higher frame rate can happen in certain circumstances.



If the bounding volume of a scene (or part of a scene) is completely within or completely outside the frustum of the camera, jme does not continue checking the children to see if they should be rendered. Thus, if you are looking at a scene and have then whole thing in view, you will get a higher FPS than if you looked a bit to the side and the bounding volume is clipped by the frustum.



To help visualize this, you can call drawBounds(your root node) in your render method and try getting the whole scene inside the frustum, then move the camera so it is viewing only part of the scene, then finally, move it so none of the bounds are viewed.



Not sure if this is what is happening to you, but just so you are aware of it…

Too bad on the cloning thing, then. I’ll have to look at the class hierarchy, but it seems you are saying that clones must be leaves in the tree graph. If that’s not the case (or things could be worked out so it needn’t be the case), it would be splendiferous to submerge the entire concept from application logic and make it intrinsic to model loading – a database of clone nodes could be maintained for each model resource loaded so that subsequent requests for another copy would produce a clone against the “cached” model.



I’ll try a clone arrangement of this ship model now. FYI the 3286 face version used around 2.2MB each when loaded (which is why I ask about whether the graphics layers may not be unnecessarily doubling my faces for me).



Hmmm… looking at the source… can a Model be cloned? It seems as though only a Geometry can be cloned, and Model is not a Geometry. That seems unfortunate… is there a workaround means of doing this?



tone

Ugh, yeah you’re right. Clones were added in as a last minute kind of thing just playing with possibilities of speeding up huge amounts of objects in the scenegraph. So it’s definately got some flaws (major ones at that).



Now that others are looking into using it, I’ll reinvestigate it, and possibly make it do what you want it to.



I see the ambiguity that you were running into with Clones. I’ll see what I can do to possibly create some sort of caching mechanism to allow for more efficient model loading.



If you have specific requests on this front, let me know I’ll see what I can do.

That would be great. I particularly like the idea of the savings in memory footprint could be made transparent to the external app calling into jME.



I wonder if Model’s Geometry/Texturing and its Spatial-ness and animation state could be threshed out a bit in future. In that way, instances of a model could share its basic representation and yet have their own position/orientation, animation state, and perhaps even overriding textures and/or overlaying decals customizing the underlying shared representation.



That said… you guys are doing great work and at surprising speed.



tone