Can submesh transform matrixes be retrieved?
Can submesh transform matrixes be retrieved?
Is there a way to get each meshbuffer's(submesh's) transform matrixes from a skinned mesh? I built a realy slow submesh distance sort function and now to speed it up I want to only update distances that have changed. My new theory of approach is like a mini scenegraph for submeshes. I'm using http://archive.gamedev.net/archive/refe ... index.html for guidance.
Re: Can submesh transform matrixes be retrieved?
You can access the joints from ISkinnedMesh. And with IAnimatedMeshSceneNode::getJointNode you can access the bones. One of those two will likely get you the matrices you want.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Can submesh transform matrixes be retrieved?
OK been thinking this over a bit. It looks like I can't just tell if a given submesh has moved using its transform, I have to see if it's bones moved and collect matrices from each bone that affects the submesh and combine them into 1.
Alternativly I could have the node store the last aabbox near and far for each submesh buffer and loop through and test bounding boxes to see if they moved then use an insertion sort to move objects into correct order.
It seems better to me at the moment to use an already existing loop and save a little memory by adding a std:set to the node's onanimate and argue it into the mesh's animatemesh function. Then add bone meta data to the mesh telling me what submesh buffers are affected by each bone(in my case the meshtype includes this data just need the loader to read it). Then when the animate mesh function detects that a bone should move, it can log the affected submesh buffer index in the set at the end of animatemesh the set will have 1 ID for each modified submesh and onanimate can move them into position with insertion sort. Probably a render list will be good enough and I won't need an rtree even though they sound cool.
Alternativly I could have the node store the last aabbox near and far for each submesh buffer and loop through and test bounding boxes to see if they moved then use an insertion sort to move objects into correct order.
It seems better to me at the moment to use an already existing loop and save a little memory by adding a std:set to the node's onanimate and argue it into the mesh's animatemesh function. Then add bone meta data to the mesh telling me what submesh buffers are affected by each bone(in my case the meshtype includes this data just need the loader to read it). Then when the animate mesh function detects that a bone should move, it can log the affected submesh buffer index in the set at the end of animatemesh the set will have 1 ID for each modified submesh and onanimate can move them into position with insertion sort. Probably a render list will be good enough and I won't need an rtree even though they sound cool.