Is the xbuf repo on GitHub up to date to the .9.1 version?
yes, jitpack compiles it from github
What happens if you clean up the editor by removing the Walking action, lamp and lamp.002?
I know that someone said you don’t have to gap the tracks but its not right to not gap them either.
Is your timeline equal to the total of all track lengths combined?
I’m really interested in this protocol buffer stuff. Whats the final file size for xbuf compared to without xbuf?
Yeah, protocol buffers are pretty shnazzy. I can’t tell you how xbuf file sizes compare to say, Ogre or Blender file sizes, but since the protocol buffer format was designed to be a highly efficient network wire format I’d guess that the difference is going to be pretty significant. It does all sorts of tricks like compressing integers (“32-bit” integers only take up as many bytes on the wire as is absolutely necessary to store an integer of that magnitude, if I remember correctly), and it’s got a whole bag of space-saving tricks.
Sorry for answering so late, but would having transforms unapplied not lead to broken animations with blender loader anyway?
I did the model in 2015 so I don’t remember what I did but I will try your fix. I noticed that at least the latest blender importer import (but I might have worked on the blend file) also has wrong rotated attachment nodes, so probably this really comes into play
It’s not yet equal but I am also uncertain about how to remove the Walking Action, I guess it only shows up since I selected the Action?
I don’t know, maybe, if the armature has the unapplied transforms. Save a backup copy, just in case.
Btw the only warnings the script throws is “Unsupported Texture None” and things like:
INFO: add relation: 'AnimationKF'(-9223363260216813630) to 'TObject'(-9223363260229245472) INFO: add relation: 'AnimationKF'(-9223363260216813644) to 'TObject'(-9223363260229245472) INFO: add relation: 'AnimationKF'(-9223363260216813616) to 'TObject'(-9223363260229245472)
That’s only debug data, it tells how the scene is reconstructed from the xbuf file. Yeah, maybe the level should be changed from INFO to FINE.
Not sure about the unsupported texture, but it shouldn’t cause the issue you are reporting here.
Yes. X the action in Dope Sheet and it will be removed from the NLA editor.
I have never had even 1 model import correctly using xbuf myself. There was always something wrong somewhere. Only ogre has worked for me.
@nehon Is it possible that the Skeleton Debugger is showing the Skeleton rotated around 90° in some cases or might this be another case of me missing to apply the rotation?
(@)everyone: I sent the file to Riccardo and he had a look. It turns out I was really missing to apply the transforms and his guide was correct, I was just in the wrong mode leading to the shortcuts not working. Now it seems nearly fine.
I will update this post with all the instructions when everything finally works as expected again. I hate asset stuff…
I think Jaime shows up this way… so it may be a problem with the skeleton debugger itself.
After some debugging it turns out that it’s not my code (even though its a bit weird :D)
What you’ll see below is the discrepancy between blender importer (to the right, it doesn’t support the wireframe modifier) and xbuf (to the left, it does fail for me):
Now some explaining: The hitboxes are separate geometries which are moved to the non-animated position by the artists (NOT the T-Pose!). Upon loading, I try to re-parent the hitboxes to the attachment nodes, so that it stays at the same world transform. (I do this by setting the local transform of the hitbox to: inverted attachment node transform combined with old hitbox world transform).
As you can see it works fine for blender. Cyan shows the attachment nodes of the hitboxes, so I am uncertain why they are wrong in blender, leading to the hitboxes to be right? Could it be that the attachment nodes get mode after the first update tick, so that I need to adjust my hitboxes after that? But then I wonder why they are correct in blender?
Edit: Here the code, now that xbuf should be correct it seems like I could be doing things wrong (since the boxes are rotated 90° around the origin):
Transform tHb = hb.getWorldTransform().clone(); // Before being added to the attachment attachNode.attachChild(hb); hb.setLocalTransform(tHb.combineWithParent(attachNode.getWorldTransform().invert())); // hb.setWorldTransform(tHb)
Have you tried FBX exporter?
Edit: This post discusses the FBX as being integrated into the engine but it looks like it never was implemented into the SDK.
Well, I don’t see how FBX could help me here since XBuf does it’s job, and blender is just working, because the attachment nodes start at (0/0/0) and then stay at (0/0/0).
The SDK supports FBX by: FBX->Blender->j3o, so it would leave me with the same Blender Bug thing.
I managed to fix the bug though, by delaying the hitbox attachment up until I get the log message “Hardware Skinning engaged”, which is a bit sad because I wanted to place the hitbox once for every instance of this model.
@nehon Do you have any idea how I could check when the npc was first visible and hence has hardware skinning enabled? Or is there an easy way to force calculating the t-pose once? (Be it using software skinning or manually calling render)?
There is no way… I’m not sure I get what your issue is.
However you have a renderManager.preloadScene(Spatial) method that sends the spatial to the GPU and compile the shaders needed to render it.
It will resolve the hardware Skinning stuff.
I think this is a hack and not actually using the engine BinaryExporter to convert the file. Please correct me if I am wrong. If you use the BinaryExporter you can convert to j3o and skip blender.
Something like this.
I am not sure if it would help.
Note: I get 2 phantom warnings when converting a model,
FBX model isn’t using correct forward axis sign. Orientation could be incorrect
FBX model isn’t using meters for world units. Scale could be incorrect.
Both warnings are wrong and the model does load correctly.
Blender fbx importer is more mature that jme’s.
Ill clarify since the thread morphed into another direction.
Doesn’t use ogre, cant use blender importer, having trouble with xbuf, so try fbx without using the importer was my suggestion.
As for the second problem darkchaos is having,
Yeah, Riccardo is right. Back then we only had the option to use blender as xbuf importer and I’ve heard that fbx isn’t quite ready yet, however there were some PRs regarding the importer, so Idk.
So since the problem is now solved, here’s the aftermath:
Blender Importer has a bug in that, at least for my model, it doesn’t move the attachment nodes to the position of the rest pose, when you don’t call any Animation.
Xbuf works fine, but jme only places the attachment nodes after the model has been rendered first. My issue here was that I calculated the local transform offset when the attachment node wasn’t placed yet (so at (0/0/0)). When the attachment nodes were moved, the offset was wrong obviously.
This wasn’t the case with blender importer. Since it never moved the attachment node, the offset was correct however the hitbox wouldn’t move with the bone.