[feature request]Mesh and billboards replication.

Mel · Post by **Mel** » Fri Feb 13, 2009 10:52 pm

It is a thing that can save time when designing large open environments (terrains, for instance, highly detailed trees) A Mesh replication system.

The idea is to take a base object, and replicate it all along the surface of another mesh, perhaps in the very surface, or a little displaced along the normal, axis or normal aligned,and rotated and scaled randomly on all the axes.

In the same fashion the particle system works, this replication could be used to place "billboards" over a surface, and that the entire object was a single mesh, or that perhaps, when replicating a mesh, the instances of the meshes could be culled with the distance, so perhaps, when making a number of replicas too high, or when those were too far, it only was rendered the closest objects

How about it?

hybrid · Post by **hybrid** » Sat Feb 14, 2009 10:20 am

I think I don't get the idea. Could you give some screenie or more info?

Mel · Post by **Mel** » Sat Feb 14, 2009 4:51 pm

The idea is to take a base mesh and replicate it, scattering instances over the surface of another mesh (a terrain, or another kind of mesh) so, each instance could be culled with distance, having each of them its own rotation and scale. I spoke of billboards too because it could be great that they could be used too to create also the effect of grass.

like this

The idea is to have a sort of structure that allowed the rendering of multiple meshes, but instead of having them in multiple scene nodes, just one, giving perhaps space to use VBOs with simple meshes. instead of having very little amount of vertices inside a VBO and much VBOs. Besides, as it would be the replication of a mesh, setting the materials for all of them would be faster than setting much times materials and rendering all the objects on their own. And much more things that can be optimized just because they're a great set of objects with the same properties.

fmx · Post by **fmx** » Sat Feb 14, 2009 6:40 pm

This could be done with a custom scene-node, especially if the meshes are simple enough like billboards etc.
Isn't that what you've done in your screenshot?

wouldn't this features be going beyond the simple requirements of a "rendering" engine?
I don't think irrlicht needs something like this "by default", because it can be achieved fairly easily with a custom scenenode.

just my opinion, I don't speak for everyone ofcourse

Dorth · Post by **Dorth** » Sat Feb 14, 2009 7:21 pm

Dunno, seems more in line with a rendering engines than the recent clamor for physic, gameplay, etc. we've been having those last few weeks. At least, this is clearly a rendering issue/optimization.

bitplane · Post by **bitplane** » Sat Feb 14, 2009 7:28 pm

You could always use my Batching IMesh, it would need adapting to work with 32-bit indices and VBOs though.

Sounds like what you really want is support for hardware instancing, which allows you to efficiently render the same mesh in different positions in one call, but is only supported on SM3 and later cards. I guess if this was added to the hardware drivers we could have an IVideoDriver::drawMeshBuffers(IMeshBuffer* buffer, matrix4* matrices, u32 count) method which uses instancing if available, and users could just create a custom node that calls this method.

Mel · Post by **Mel** » Sun Feb 15, 2009 5:18 pm

@FMX, well, the engine now also has light volume scene nodes, i don't know if those are also much within the needs of a rendering engine. At least for the idea i have of a light volume.

No, i wasn't asking exactly for hardware instancing, but for instancing itself within a scene node. The scene node itself would be the set of instanced meshes. In other words, when that node got procesed, all the instances would be rendered.

vitek · Post by **vitek** » Sun Feb 15, 2009 9:43 pm

You say there would be one scene node, and that node would have many instances. What would happen if you called node->setPosition()? How is that handled?

It seems that if you wanted individual instances that were to be manipulated, you really need to keep individual scene nodes. If you don't do that, there is no way [from the ISceneNode interface] to manipulate the individual instances.

If you want just one scene node that has many instances, but the instances are not manipulated independently, then you can already do this by adding mesh data to the mesh buffer of the mesh scene node.

Travis

Mel · Post by **Mel** » Mon Feb 16, 2009 1:00 pm

Well, you can imagine a scene node where the position of it could indicate the center of a circle where the instances might appear, so, if the set position method was used, the instances outside the circle would disapear, and it would create another ones inside the circle.

Maybe the term "instancing" is what is confusing here. Indeed, it would be a scene node with many replicated meshes, but also, the point of this is that the instances would appear in the surface of the scene node we would use as distribution mesh (i.e. distribution object is the mesh we use to base the replication, and the "instances" would be the meshes appearing over the surface of the distribution object). I think the most apropriate term would be "Scattering".

the point i'm asking for here has more to see with Irrlicht having its own methods to create (not rendering them) complex scenes fast. If it could scatter meshes on its own, not needing to place all the objects by hand, that could improve the look of the scenes, and would make easier for creators to make good scenes easy, because of that i've also pointed out that the replicas would appear in the surface of a base object.

JP · Post by JP » Mon Feb 16, 2009 1:13 pm

sio2 did something like this (or atleast said something like this would be useful) for IrrPhysx 0.3, the version he uploaded with the water physics... But I don't think the source is available and I've not been able to get in touch with him...

Pyritie · Post by **Pyritie** » Mon Feb 16, 2009 1:24 pm

Mel wrote:Well, you can imagine a scene node where the position of it could indicate the center of a circle where the instances might appear, so, if the set position method was used, the instances outside the circle would disapear, and it would create another ones inside the circle.

Maybe the term "instancing" is what is confusing here. Indeed, it would be a scene node with many replicated meshes, but also, the point of this is that the instances would appear in the surface of the scene node we would use as distribution mesh (i.e. distribution object is the mesh we use to base the replication, and the "instances" would be the meshes appearing over the surface of the distribution object). I think the most apropriate term would be "Scattering".

the point i'm asking for here has more to see with Irrlicht having its own methods to create (not rendering them) complex scenes fast. If it could scatter meshes on its own, not needing to place all the objects by hand, that could improve the look of the scenes, and would make easier for creators to make good scenes easy, because of that i've also pointed out that the replicas would appear in the surface of a base object.

Do you mean sort of like "here's an area, here's a node, now make X copies of it inside the area"? Or make it keep one set of geometry but then "instance" the geometry in various places?

Mel · Post by **Mel** » Mon Feb 16, 2009 1:31 pm

My idea was exactly that "Here is an area, here is an object, replicate it X times".

FuzzYspo0N · Post by **FuzzYspo0N** » Mon Feb 16, 2009 1:37 pm

its replication, not instancing. this is implemented in lot of game engines, and i dont think it fits in a rendering only engine, then again, irrlicht has filesystems and all sorts of weird stuff, so why not.

defining these are set by a point, and a radius, and some parameters.

point x,y,z : radius : 100 units, random seed, minimum dist apart, maximum dist apart, repllicator amount (100 trees), etc...

Mel · Post by **Mel** » Mon Feb 16, 2009 1:44 pm

It is much more a helper rather than a rendering feature. But it would enable the engine to create complex scenes fast without the need to set all these objects by hand, and also, i think it could save the overhead of having 100 scene nodes to navigate through when rendering, or when processing them.

hybrid · Post by **hybrid** » Mon Feb 16, 2009 2:00 pm

Ok, just go ahead and implement it. We'll see if it fits into Irrlicht or irrExt then.
BTW: Isn't it Schmitt, Smichtt looks pretty wrong...