Jump to content
You are about to reply to a thread that has been inactive for 3609 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

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 ....

 

 

 

 



Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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.

Link to post
Share on other sites

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. 

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 3609 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...