It is something i've thought of, while taking a look at the Assimp features, and also because of some user's questions, and it would be to have the ability for irrlicht to construct skinned meshes in runtime and split them.
Say you have two skinned meshes and want a mesh that has all the bones and meshes together, but without resorting to attaching one mesh to the other, perhaps, to grant that you draw the whole mesh with a single draw call, perhaps to have a finer control over the joints count. This could be used to combine hierarchies, i.e. say that both skinned meshes share common joints, then, those joints would be added only once (thus the word union, you would be uniting the sets of joints), and the rest of joints would be placed accordingly along with their attached vertices. Or perhaps, say you have an empty skeleton loaded, you've loaded just the joints, and you want to populate them with the vertices of other skinned meshes that share some of the joints.
And also, a sort of inverse step, to split meshes into other meshes which are granted to have a smaller or equal amount of bones to a given number. Some times because of hardware/software limitations, you can't have all the bones you want in a mesh, so you have to end resorting to having more meshes rendered. This operation would split any mesh that had a larger amount of joints than any given number into meshes that had less or that number of joints. The base joints would remain the same, but the meshes would be referenced by a limited amount of joints.
These operations could be placed in the mesh manipulator, or perhaps, be part of the skinned meshes. i.e. a sort of "union" operation which would pick another skinned mesh. and a "split per bone count" operation which would grant each submesh from the skinned mesh has the appropriate amount of bones.
Comments? criticisms? tomatoes?...
Feature requests-skinned meshes: mesh split and mesh union
Feature requests-skinned meshes: mesh split and mesh union
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Feature requests-skinned meshes: mesh split and mesh uni
I think you are crossing the line into modelling! But you can do this in "user space", so why not put your code into irrext. It doesn't belong in the core product but can be accessed in this way.
Maybe Irrlicht should have a 'contrib' directory, say 'source/contrib'. Then code like this could be downloaded with the main distribution.
Maybe Irrlicht should have a 'contrib' directory, say 'source/contrib'. Then code like this could be downloaded with the main distribution.
Re: Feature requests-skinned meshes: mesh split and mesh uni
Well, i think it would be a useful addition. Making sure that any of the meshbuffers of a skinned mesh references less than a given amount of bones would enable the engine to use any of the hardware skinned meshes solutions that there are already, instead of having to rely on software skinning, for instance. If skinning has a problem is the large variety of cases it may present, thus, having the posibility to split a mesh of an arbitrary amount of joints into submeshes of fixed, or at least, predictable amount of joints, is an advantage.
And the mesh union would provide a more natural (it would be a skinned mesh attached to a skinned mesh node anyway) way to have skinned meshes inside the engine built of random pieces, instead of attaching them as parent-child meshes, as they would require less animations, less special cases and less bones (less calculations) while enabling irrlicht to present a much more variated content by default. Precisely, as an editor, i think it would be great to have those tools by default within the engine of my choice, or at least, that they could be transparent to the programmer.
And the mesh union would provide a more natural (it would be a skinned mesh attached to a skinned mesh node anyway) way to have skinned meshes inside the engine built of random pieces, instead of attaching them as parent-child meshes, as they would require less animations, less special cases and less bones (less calculations) while enabling irrlicht to present a much more variated content by default. Precisely, as an editor, i think it would be great to have those tools by default within the engine of my choice, or at least, that they could be transparent to the programmer.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt