How do instancing work in LE2?

[Roland]

In the Editor:

If I drag say 10 OilDrums into the scene.

Will that result in one copy of the mesh and 10 objects just using that mesh OR

will it result in 10 copies of the mesh.

 

In C++:

If I load the scene mentioned above..

Will that result in one copy of the oildrum mesh and 10 objects just using that mesh OR

will it result in 10 copies of the mesh.

 

Here is the first part of a little bridge I'm working on.

As you can see I have 10 objects of the mesh 'Pole'.

Will this result in one or 10 meshes in the my C++ program if scene is loaded

 

 

[Canardia]

LoadScene uses LoadMesh, which is the best way to instance models.

 

You could theoretically use CopyEntity to make instances of the model too, but I think it does not work perfectly, or then I had some other issue with occlusion culling when I tested it.

So always use LoadModel to make perfectly instanced models.

 

LoadModel doesn't load from disk if the model is already loaded, so there is no additional disk activity either.

[Flexman]

I've been using TModel.Copy()

 

Your pole (or oildrum) will be stored as a *single* object which is drawn 10 times during the scene render.

 

If you manipulate a vertex on your pole then all of your poles would change, likewise if you paint one of your poles with a different material then all of your poles will change to the new material.

 

As Lum suggests LoadModel() works too, if already loaded it returns a pointer to the object.

[Josh]

Loading a model, loading a mesh, or copying either will all result in the minimum number of vertex and indice buffers used. Every instance in the engine will use the same data and be rendered in a single draw call.

[Roland]

Loading a model, loading a mesh, or copying either will all result in the minimum number of vertex and indice buffers used. Every instance in the engine will use the same data and be rendered in a single draw call.

Thanks Josh. Exactly the answer I was hoping for

[Guest Red Ocktober]

Thanks Josh. Exactly the answer I was hoping for

 

yeah... me too... i was getting a lil confused with the term "instancing" as it applied to Leadwerks objects...

 

--Mike

[VeTaL]

LoadScene uses LoadMesh, which is the best way to instance models.

 

You could theoretically use CopyEntity to make instances of the model too, but I think it does not work perfectly, or then I had some other issue with occlusion culling when I tested it.

So always use LoadModel to make perfectly instanced models.

 

LoadModel doesn't load from disk if the model is already loaded, so there is no additional disk activity either.

 

This is quite usefull for me... What about creation of new FAQ?

[Rick]

If you manipulate a vertex on your pole then all of your poles would change, likewise if you paint one of your poles with a different material then all of your poles will change to the new material.

 

This is the part that I think should change. Would be nice to store materials per instance if we want to, just like position, scale, rotation is stored per instance. Move, rotation, scale to a location, find out what material it needs and paint the material on the model, then draw it. Rinse and repeat. The instances should have a default material that is generally defined from the model itself and mat files, BUT if in code we paint a new material on one instance, that instance gets it's own pointer to that material instead of using the default. Best of both worlds there I think, and I wouldn't think it hard to do. Yeah it would add some time to the drawing process but we as the users can control that.

 

I know people have talked about not wanting instances sometimes, but in most cases I think the reasoning is because of wanting different materials on the same instance. Why create entirely new copies of that model when you can just store different materials per instance. Still save on storage space by having 1 model loaded and get the flexibility to have multiple materials per instance. It just seems odd why this isn't the case. It's so common in video games to use the same model but have different materials to not make your scene boring. I mean MMO's survive this way.

[Dozz]

If a model is instanced in a Max scene, does it automatically get instanced when exported to LE?

 

Also, if a model is instanced thousands of times in a scene, does it make a big difference in speed to optimise the triangle count to the point of deleting faces that will never be seen (for example the bottom faces of a box that is always grounded)

[DNC]

This is the part that I think should change. Would be nice to store materials per instance if we want to, just like position, scale, rotation is stored per instance. Move, rotation, scale to a location, find out what material it needs and paint the material on the model, then draw it. Rinse and repeat. The instances should have a default material that is generally defined from the model itself and mat files, BUT if in code we paint a new material on one instance, that instance gets it's own pointer to that material instead of using the default. Best of both worlds there I think, and I wouldn't think it hard to do. Yeah it would add some time to the drawing process but we as the users can control that.

 

I know people have talked about not wanting instances sometimes, but in most cases I think the reasoning is because of wanting different materials on the same instance. Why create entirely new copies of that model when you can just store different materials per instance. Still save on storage space by having 1 model loaded and get the flexibility to have multiple materials per instance. It just seems odd why this isn't the case. It's so common in video games to use the same model but have different materials to not make your scene boring. I mean MMO's survive this way.

 

 

This is where I would think an interface would come in handy, C++ supports multiple inheritance which would allow even more extensions for multiple instances of the same objects. Please correct me if I'm wrong.