Mesh istances

[Naiman Broome]

Hi I woul dlike to knwo if it would be possible in mesh creation process to make use of istanced submesh objects as parts of the same mesh

In order to save drawcalls, the some graphic engines combine identical elements of an object into one renderpass. It is mainly used on complex objects, which have a lot of separate internal parts, like fences ....

Thi could save also the polygon count and allow more olygonal meshes without the burden of an equivalent mesh that doesnt make use of istanced parts ....

 

 

 

 



[leliel Mirihi]

Short answer is no. Long answer is doing instancing in sl has historically been a hard problem due to prims so LL never bothered to implement it. Sculpties and mesh change that, but there are still some challenges to over come before you could do it. The biggest problem is state tracking, the way the viewer keeps track of objects is just not set up for instancing. So yes you could do it, if you spent a few months rewriting how the viewer manages objects.

[Nyx Linden]

as mentioned in the usergroup this week, we respect instance flags in uploaded collada files, but the resulting instances will be able to scaled / modified / limited independently from each other. Using the same model multiple times in your build will save downloading / loading times.

[Naiman Broome]

Yes but I didn't mean instances of the object but Instances of sub object elements ....

Imagine a fence made of 100 bars , and of those just 5 are modeled and the others instanced ...

 

This opposed to a 100  bars fence that each is different from the other...

[Drongle McMahon]

The suggestion is that streaming data size can be greatly reduced by using instancing for repeated elements within a single mesh object, together with transformations of the instances. The fence is a good example. My favourite is my fractal tree where the branches are repeats at ever lesser scales. It is even more relevant where a larger unique structure additionally contains repeated small structures (e.g. windows, tiles and beams in a house).

The instancing mechanism is available in Collada. However, it is already interpreted in a different way by the uploader, which instantiates the instances as separate objects. Thus the fence using instanced posts has a separate object for each post. For a fence with, say, 12 simple posts, that translates into 12 prims while the uninstanced version translates into 1. Given also lots of other disadvantages, nobody is going to use that. That is a pity because it means the potential download savings will not be made. As it is instancing is only sensibly usable where each instance would contribute at least one prim to the cost of the single object without instancing.

As instancing is already used, this suggestion has to be a request for adding a flag of some sort to change the interpretation of instancing, to flag it for intra-object replication. In yesterday's meeting, Runitai (Davep) explained that, although some download data might be saved (but see below), the instances would still have to be expanded for the physics engine and for the rendering engine. Allowing a thousand apples on a tree to cost one prim because they can all be in one tiny instanced mesh would defeat the purpose of the cost system to control resource loads, as the loads on the physics and rendering engine would be the same as in the uninstanced case. Some contortions of the accounting system would be required to accomodate this. It is hard to see how they could end up being much different from the present one-prim-per-instance cost. It might still be worthwhile for the download size reduction, but that will have to wait.

There is an old jira about this in some more detail. See CTS-70, especially Runitai's comment, and CTS-78. This is a bit outdated because there is no "scene importer" any more, but it is the same issue. The scene importer was originally the only way to import multiple objects at one go. So here we were talking about different interpretations of instancing in scene and model importer. As their functions are now merged, this is no longer a possibility.

[DanielRavenNest Noe]

What you are talking about is in the general category of "procedural generation".  It is already being used in some 3D graphics, and is likely to increase because it is so efficient.  Some examples:

* Cryengine 2 and 3 vegetation --  You define one geometry, like a tuft of grass, and a set of parameters for spacing, random size variations, etc.  Then the graphics engine places as many in view as needed according to the parameters.  The server does not need to track where each one is, since they are generated locally on your PC.

* E-on Software "Vue" landscapes -- Terrain and plant detail are generated by a fractal formula as needed.

* Allegorithmic "Substance" materials -- This generates textures and other bitmaps from a set of parameters.

The common feature is reduced storage and data transfer needed, at the expense of some more calculation when used.  Since computers and graphics cards only get faster with time, this gets easier to do.

What is preventing the efficient use of mesh instancing is the lower bound of exactly 1.00 prims and no less for any object.  If prim accounting had more decimal places, we could do things like a fence out of repetitive simple objects and not get overcharged for the complexity. 

[Drongle McMahon]

Hmm. There's a thing in "changes since last build" in viewer 230677 that says "separating meshes from instances". I have no idea what that means or whether it will affect anything we have discussed here.

[Naiman Broome]

No Daniel is not about procedural generation , that's another thing is about how to design instances in the same original model ... anyway seems that LL has no plans for optimizing the mesh right now .....