QtMeshEditor

[fernandot]

hmmmm I got this error when trying to load the robot.fbx

terminating due to uncaught exception of type Ogre::ItemIdentityException: ItemIdentityException: Bone named 'Shoulder_R' not found. in Skeleton::getBone at /Users/fernandotonon/ogre/OgreMain/src/OgreSkeleton.cpp (line 481)

ok, let me try to fix importing this file and also try to adapt the code to at least keep the same signature as the ogre assimp plugin. I really tried to fix it, but as I only do it in my spare time, having to understand the code and try to fix was too difficult, I needed a bigger chunk of time to really focus on it.

now that I got it working, for most cases at least, I'll try to get back to fixing the plugin.

[fernandot]

Eventually, I'll get there.

The problem is that it is a bit more complex model, and also, it is not as well structured as the mixamo in terms of hierarchy. Thanks for the challenge, when the importer gets able to load this file, it will be much more resilient

I'll keep trying to improve to read this, then work on the plugin...

[fernandot]

The robot is much bigger than the rumba dancing man

IDK if this is the expected behaviour, but in the first frame of the animation the robot gets laying down

after that, it walks normally

I must say that it looks better than when importing in blender

Tomorrow I'll try to wrap up this version and then I'll investigate this first frame that looks weird, and then try to adapt to the plugin.

[fernandot]

I released the new version with a few fixes from the robot.fbx file.
But it is still rotating down in the first frame, I still need to further investigate this.

I'll try to have a second look at the Ogre Assimp plugin, maybe now that I got a bit more experience I can spot where the error is.
The plugin code is a bit more complex because it handles more scenarios in a way that is compatible with a wider range of applications, while on mine I'm just worried about running on a single project

https://github.com/fernandotonon/QtMesh ... /tag/1.8.1

[fernandot]

Hi folks,

I just released a new version, and now it loads the embedded diffuse texture from the Assimp models. Before it looked for the image in the filesystem.

Another great news is that I sent a PR for fixing the Assimp plugin, I had the same issue when building my version, so I decided to double-check, and the problem was the same... haha It is a small change, but very difficult to spot, sorry for taking that long

I improved the importer in QtMeshEditor, removed a bunch of workarounds, and split the code into different parts (mesh, material, bones, animation) it looks cleaner and more maintainable, I also added some unit tests. I want to include more functionalities there, maybe an exporter in the future.

[paroj]

Another great news is that I sent a PR for fixing the Assimp plugin, I had the same issue when building my version, so I decided to double-check, and the problem was the same... haha It is a small change, but very difficult to spot, sorry for taking that long

awesome work! I feel the pain of finding stuff like that..

[paroj]

Another great news is that I sent a PR for fixing the Assimp plugin, I had the same issue when building my version, so I decided to double-check, and the problem was the same...

do you maybe have an idea why the robot still looks off when imported with the Assimp plugin? From the looks it seems the bone transform is not quite correct, but I cant pinpoint it..

edit: it seems we ignore mOffsetMatrix in the plugin. Tried to add it, but the whole bone processing in the plugin seems to be a convoluted mess..

[fernandot]

U mean that weird rotation in the first frame of the animation right?

I need to further investigate it, Maybe it can be an issue on the Assimp side or an issue in the model data. It looks weird when loaded in Blender as well (in a different manner ). Both the QtMeshEditor custom importer and the Assimp Plugin present the same glitch on the first frame for this model.

On QtMeshEditor importer it considers the mOffsetMatrix, but even though it looks weird.

The FBX models I get from Mixamo load just fine either on Ogre Assimp Plugin, QtMeshEditor importer or Blender. So it might be a problem with this specific model.

I'm trying to build the last Assimp view, so we can see how it behaves when loading the model.

whole bone processing in the plugin seems to be a convoluted mess..

haha yep, it is a bit hard to follow what's happening. That was an inspiration for me to split the process into different classes on the QtMeshEditor importer, so it would be easier to maintain If folks don't mind, we can replace it in the future, if the custom implementation supports all the use cases currently supported by the plugin, I can change the methods signatures to keep the same as the plugin and create a PR for replacing it, but first I need to polish it better.

[fernandot]

I wasn't applying any transformation to the root bone, it doesn't have mOffsetMatrix, because it is an aiNode instead of aiBone, but it has the mTransformation.

When applying the transformation to the root bone, it looks like this, the robot starts lying with his back on the ground, gets up, and starts walking. IDK if it is the expected behavior, but at least it makes much more sense... haha

I think it might be right (applying the transformation to the root bone) tomorrow I'll try to wrap this up and verify if the plugin also does it.

[fernandot]

More info: still investigating, but when I load with only the aiProcess_PopulateArmatureData it doesn't get that weird glitch.. it still looks bad and rotated sideways, but the animation doesn't do that rotation in the first frame.

It seems something related to the Assimp post-processing flags we are using, not how the data is processed in the importer.

[fernandot]

I think I found it, the first frame glitch was because of this flag:

Code: Select all

aiProcess_FindInvalidData

But besides that, I think the animations look weird using the plugin importer because it doesn't limit the number of bone weights per vertex, I remember reading somewhere in the documentation that Ogre only supports 4 bones per vertex, so I did this weird logic to pick the 4 most relevant and apply only those. The Ogre Assimp plugin importer just tries to apply without considering this. It might be the problem, I'll try to fix it there to see if it works.

[paroj]

Ogre only supports 4 bones per vertex, so I did this weird logic to pick the 4 most relevant and apply only those. The Ogre Assimp plugin import just tries to apply without considering this. It might be the problem, I'll try to fix it there to see if it works.

Ogre already does that internally, see: https://ogrecave.github.io/ogre/api/lat ... 53af4308ef

I think the issue is that the plugin currently completely ignores mOffsetMatrix. You could try verifying that by skipping that in your code and see whether the animation looks similar to the plugin.

[fernandot]

Nice, thanks paroj, I removed that logic from the custom importer and it behaves the same, so at least, the code is much simpler now...

I've been able to replicate the same result as the FBX importer from Blender, so IDK if it counts as a win... haha

Jokes apart, on the custom importer, it looks good now, but the T-pose stands on the Z axis while the animation happens standing on the y axis...
I thought it could be because I'm not applying the root transformation when processing the mesh, when I did it, it looked exactly as it does in Blender.

I also tried to load it in the Autodesk FBX Review, there it is in the y coordinate as well, but even the T pose is in the same axis.

When loading using the Assimp plugin, it gets that weird animation, but at least the T-pose and the animation are oriented on the same axis.

edit: It might be related to this as well: in the custom importer, I'm building up the skeleton, calculating the bones' orientation based on the parent bone, when I do this, I get the global transformation by getting the inverse of the matrix, and then the local considering the parent bone global transform.

But in the plugin it calculated all the transformations using only the Assimp mTransformation, and then, in the end, it got the inverse();

Anyways, I need to investigate it further, I'll wrap up the custom importer, it got better now, and then look deep into this and the plugin to try to fix and get the same behavior on both importers... at least this robot is a good challenge