I keep going back and forth on this. I’d like to know what other folks do.
I understand that Godot uses Y up, -Z forward. So I’ve been rotating my characters in model space after import. However, according to this Godot doc article, there’s an exception to this rule in model space due to most people authoring their meshes in DCCs to face the positive vector. You can then use the use_model_front and vector3.MODEL_* to compensate for your math. I tried going this route, but it just seems like an extra layer of complexity for no real gain.
So do you:
Import meshes as is (+Z forward in model space) and use the options above in your math?
Import as is and rotate 180 in model space to face -Z in model space?
Or rotate the model in your DCC to face -Y (or equivalent to the software’s convention) before importing?
And are there any pitfalls for the above to watch out for, such as odd bone space behavior on animations?
(Google translator)
In my limited experience, I’ve always used models facing +Z as they come from Blender. I don’t bother rotating anything 180 degrees. I’ve seen videos where they do it, but I don’t see any advantage to constantly doing that with all the models.
Also, if you add a camera, point it towards -Z, which seems more correct to me, regardless of how you end up positioning it later.
I think the Godot documentation implies that the previous practice of rotating models isn’t entirely standard and that what I do now is the proper approach.
I think the only problem I’ve encountered is when using a method like “look_at”, where you normally have to specify that your model points towards +Z. I also think it’s advisable to ignore the constant “Vector3.FORWARD” since it points towards -Z.
Ultimately, it’s a convention you have to decide on, but if I have to choose, I prefer the one that saves me from having to rotate the models.
I was thinking about trying this method, but the backwards previews would be triggering. Hah
The Godot doc I linked specifically calls out that use_model_front is meant to be used with look_at(). I suppose it’s longer but more human readable.
You mention animations. Does rotating the root component of a rigged object have an effect on animation? I would guess not since the animations are in bone space and 2 levels down from the root parent.
At any rate, it would seem the definitive answer is that there is no definitive answer!
Nope. Specifically you have to rotate the node typically named Rig. It’s the node the Skeleton3D node hangs from, but not the root node - as that cannot be translated.
That’s what I meant by “root” - the top level node of the character scene. And then bone space starts 2 levels down from there: Character/Rig/“root” > Skeleton3D > root bone. But yeah thanks I’m glad this wont cause issues with animation.
But that also says that by default -Z is treated as forward, so yes putting true in all the look_at() functions also does the trick.
The answer that it doesnt matter is quite acceptable … take this node tree for example:
– Character
– – model
– – – root
– – – –skeleton
if you rotate the character to face -Z then the model and all child nodes inherits that.
Either you rotate the Character node, or an internal node when moving, so ‘model’ could be rotated 180 degrees instead. You could even rotate the skeleton.
I dont ever have any issues with the model front, the only problem i ever get with look_at() is the debugger complaining that source and target positions are the same, when they are not.
I mean, if you move a character with
velocity = global_basis.z * SPEED
and run the game and it walks backwards, then you can just change the script to use the negative. You usually dont need to know which way is forward or left.
Yeah that’s why I’m so at odds with it. Just seems inconsistent.
True, where it really gets slightly annoying is when you’re building basis matrix transformations. It doesn’t make it needlessly complex, but enough to make me have to stop and think for a minute.