Add an option to fix the Z-forward vector when importing a GLTF file #6198
Comments
|
At least, the documentation about importing from blender should acknowledge the problem and give users a viable solution. |
|
Uhm... In Blender, your character is looking towards -Y. In Godot, your character is looking towards -Z. This is consistent across both and the GLTF spec you quoted. We only swapped letters, not directions. The difference here is not that the character is rotated in an unexpected direction, but that the camera is on the other side. The editor camera is placed at a positive Z coordinate, while in Blender it is placed at a negative Y coordinate. There is nothing functionally wrong here. And to me this makes sense, since for the purposes of gameplay we want to consider viewing a character from their back side. Not just player controlled models.
We could add an option to automatically rotate imported models 180°... but then you'd have to flip them back around the moment you want to make them move "forwards". |
|
Maybe the real "issue" here, is that the camera defaults to the wrong location. |
|
Nope. Character is looking towards +Z in Godot. That's the problem.
EDIT: I've added captions to the proposal for more clarity |
|
Huh, can confirm. I was under the expression from my past uses of Godot 3D that this was not the case. In that case though, no need for a proposal. That's a straight up bug. The importer is actively rotating the model, already. |
|
@TheDuriel Are you sure this is a bug? I've looked quickly at the importer code and I see no extra rotations being applied other than the one described in the GLTF file. This seems to be the core of the issue: conflicting conventions between gtlf and Godot |
geowarin
changed the title
|
-redacted- (my previous text was partially incorrect) |
This comment was marked as outdated.
This comment was marked as outdated.
|
I think it'd be better if Godot followed convention and treated +Z as forward. |
|
I do not understand Z+ as forwards to be a common convention at all. |
There is no set convention for 3D software: https://docs.godotengine.org/en/latest/tutorials/3d/introduction_to_3d.html#coordinate-system |
It's easier to visualize and more practical to use because when you look top down x & y(then z as up-direction) will still be positive (just like you expect the original y up as being positive) and projections and math you do in this view don't have to be value-flipped on one axis to map to memory indices. It also practically aligns with how humans also tend to associate negative with backwards and positive with forwards, as in time and speed which maps perfectly to motion and thus vectors. |
|
A camera inherently views into a space. That space is negative, since it is inside your monitor. There is an equivalent amount of analogies that can be made to explain either direction as the default. From a technical standpoint, Z- is correct for cameras. And since cameras look "forwards", that axis should translate to your character models. In any case This issue is about the fact that: Y- in GLTF becomes Z+ in Godot, when it should be Z-. Simple as that. |
Maybe "convention" is not the best term, but it's the most common. (At least, right-handed Y-up is, not as sure about +Z being forward.) And the fact that it's not completely standardized is very annoying, I get tripped up often going between Blender and Godot. Besides, Godot is not even consistent about Z+ being forward, for example the advanced scene import window opens showing the Z+ side of the scene facing the camera. If Z- is forward that means it's opening backwards.
No? The GLTF specification states that Z+ is forward, not Y-. This is directly quoted in the proposal. If you mean Blender is converting Y- to Z+, that's what it's supposed to do. The fix is to either rotate imported GLTF files 180 degrees around the Y axis, or treat Z+ as "forward". I was just saying that I would prefer the latter. |
|
The fix is to indeed, to offer an option to rotate the axis upon import, and to enable it by default. So that the model does not flip from blender to godot. No change to godots forward axis needs to be made at any point. It's completely irrelevant that it is Z-. Literally, you will never interact with that fact while you are modelling, animating, or programming your game. In the former cases, the perceived difference should be handled by the export/import steps. And in the latter case you are working with the FORWARDS constant provided by Godots various types. Lets not make this proposal about something it's not. An alternative Fix would be to advise Blender users to configure their axies before export, something blender is fully capable off. And which is a standard step in asset production targeting specific formats. But Godot should be nice enough not to ask of you. |
If it didn't matter, we wouldn't be discussing it.
The purpose of proposals is to make a suggestion, and have a discussion on whether it should be implemented and how. Mentioning an alternative is not off-topic.
I just said that Blender's GLTF exporter behaves as it should. Nothing about that part of the pipeline should change, if it did it wouldn't be complying with the GLTF standard. |
|
It doesn't matter that it's Z- or Y+. It matters that the model is facing BACKWARD. |
|
It seems to me that there are enough points of agreement here to converge this conversation:
If there's any other point, feel free to add, but otherwise I think that discussing adding Z+ as a forward to Godot is completely out of scope. Also, it seems like some of you got a bit heated during this discussion. I encourage you to take a pause if that's the case. |
|
Also please note that this behaviour has been the case for very long. Comments including "Godot should just do X" downplay the complexities involved when dealing with different space coordinates and skinned meshes. Please be kind and patient. |
|
Changing the Z direction (or any other axis) in the editor has already been discussed multiple times and rejected. This is a core design decision of Godot. For instance, see this and the multiple issues it relates to: To quote reduz:
I've edited the proposal to make this clear
This is interesting, I am not really familiar with the importer, can you explain what kind of problems you anticipate for this feature to be implemented? |
I don't think it was in reference to the importer. Adding a flag to the importer should be pretty straightforward (though don't quote me on that, file formats for 3D models are a special kind of hell). Qbie's request was more general to the discussion about what should be the correct way, as if this is not a cornerstone of entire rendering, animation, importing, etc systems. Saying that this should be changed to another coordinate system is downplaying the profound effect of such a change on the entire engine. |
|
Yes sorry, I misread. So real question: if we decide to implement this feature, should it be the default? So if we want to make this the default, it should probably happen before 4.0 is released? |
|
The already rejected proposals that were linked are suggesting a change away from a right-handed Y-up coordinate system, which is not what I was suggesting. I was only suggesting to change the names of the directions. That is a much smaller change. If even that is too big especially in time for 4.0 that's understandable, and it is perhaps getting a bit off-topic, but I wanted to make it clear what I said. |
|
What about replacing the Root Scale importer setting with a Root Transform? It would solve all of the issues like this without adding settings for compatibility with specific formats. |
With Transforms you only have rotation and scale available for adjustments where scale introduces other issues (with colliders, mesh normals and probably more), and using rotation results in the x axis being flipped too, so this likely won't be enough. |
Just rotating would be enough for GLTF, it doesn't just treat Z+ as forward, but also X+ as left. |
|
Then again if you take the z component from Basis.Identity as in the shoot example, the bullet will fly towards +z, which is expected as the identity basis should have forward semantics. Negating that value just to change forward semantics seems really arbitrary and doesn't make much sense in a user facing context (only maybe for core engine-internals-developers that need to adhere to other constraints of graphic libraries etc.) The last tutorial in that case also needs to negate (active instruction to change semantics) the basis forward vector. And from a users perspective, the negation part then spills to user code where it's needed to actively invert values to conform to an overlaid design decision, where it could have been more direct in the first place (which i believed to be one of godot's accessibility goals) |
|
The standard rotation for Y-is-up right-handed coordinate systems is that +X is right and +Z is back (-Z is forward).
If we spun 180 degrees around Y to keep +Y up to make +Z be forward, then that would also imply that +X becomes left and -X becomes right. That's silly, it is directly contrary to 2D and most expectations (and yeah Godot's 2D has +Y down but uh let's ignore that...). Users expect +X to be right. Now, let's talk about how this relates to Blender -> GLTF -> Godot: Godot and Blender both use the same handedness, right-handed. The difference is that they are rotated 90 degrees around X relative to each other. This is why +Y in Blender is -Z in Godot, and -Y in Blender is +Z in Godot. This is the correct mapping. GLTF itself uses Y-is-up right-handed, the same as Godot. The program doing the conversion is Blender. Blender is (correctly) mapping its +Y to GLTF -Z and its -Y to GLTF +Z. @TheDuriel Godot is NOT "applying a 180° rotation to imported models". Neither is Blender. If we want to add an option to the GLTF importer to spin the model 180 degrees, that's fine, but that's an extra feature we are adding. It's not a bug. The models are being imported exactly as-is. Godot is not doing any conversions whatsoever right now. We can just add a bool/checkbox to the importer that does this (anyone want to bikeshed on the name? something like "rotate 180 degrees around Y"), which will default to false, just like the OP proposes.
Sorry that this has caused you confusion. This article is really bad, it needs to be rewritten from scratch. I've known about it for years, but I keep forgetting about it... |
|
I did a few more tests in godot and blender and i stand corrected that the forward semantics atleast are consistent between both, (which then applies to gltf aswell), through models and shader logic:
This makes it a little less of an issue for my case. It's still some (mental/performance) overhead for flipping z in code for the rest of the worldspace logic, though not ideal, i can live with that; it's the better alternative for me, than flipping things in blender and in shader Edit: The difference in blender is how they seem to treat 'front' for the camera perspective (menu option), blender puts it on the opposite axis as godot, so one treats it like a look-at and the other as a look-with) |
@geowarin 3d coordinate spaces are a bit messy. Say for example, in the importer we just flip every z coordinate. Cool right? it should be just what we want and what we've been discussing ..? Not quite. To understand this you have to understand convention for cross products and coordinate spaces. @aaronfranke gave an in-depth explanation, but I'll illustrate the bases (pun intended) Freya holmer has a nice diagram about different coordinate systems: https://twitter.com/FreyaHolmer/status/1325556229410861056?lang=en You could deduce a 3D basis ( imagine it as a point of reference of a 3D space ) just by two vectors, instead of three, because the third vector can be inferred by making a cross product of of the first two, in the right order. Which way the third vector points, depends on the convention that you choose. Left hand or right hand (you put first vector on the thumb, second on the index, and then you point your middle finger away from your palm: you'll see that if you contort a bit and align both your thumbs and your indexes, your middle fingers will point in opposite direction for your two hands). Flipping the Z axis, as-is, means changing the entire coordinate system convention for that model. Because Godot uses another coordinate systems, then interpreting rotations of the bones and the way they skin to the mesh will become really problematic. You'd end up with bones rotating in funny ways around axis you don't expect and your character being most definitely in pain :D Like aaronfranke pointed out, simply rotating the model does still create some inconsistencies on what's right and left in the model. Likely, it can be still worked with, but i hope this comment sheds at least a bit of light of why it's not something that can be fixed just by snapping fingers.
I don't think it should not be on by default, otherwise everyone that has imported models now will have them flipped around. It can however be a project setting to be set as a default, so it needs to be changed only once per project, which to me seems ilke a reasonable compromise. EDIT: using bold to highlight parts of the text that imo are crucial to understand the big blorb i wrote. I mean in no way to "shout" with it. |
|
Godot 4 is not out yet. If this were to make it in, it could be one by default. And disabled by the 3.x to 4.x project converter. Realistically it's not going to make it in.
Would result in the model ending up mirrored as well. So it needs to be rotated. |
Godot4 is in beta stage, no more compat breaking changes.
Yup! That as well. I was trying to start from the easiest hypothetical ( "why don't we "just" move forward to +z") as a base to talk about coordinate systems and why they are nontrivial to work with. |
|
I opened a PR to add an import option for this: godotengine/godot#72753 Also worth noting is how GLTF is not self-consistent with how it defines forward. The camera spec defines forward as -Z (as a behavior of the camera's orientation), while the coordinate spec defines forward as +Z (as a convention). 
At a glance, this may seem fine, and it works for placing a camera in silly little scenes with a single prop. However, when you think about it more, if you want two objects to face each other - doesn't that mean that one of them should have a transform rotated the other way? Going further, it completely breaks down for the cases you actually use cameras for, where you expect cameras to face the same direction as the assets, like for player characters (I rotated mannequiny): 
Also worth noting is how GLTF is not self-consistent with how it defines scale. GLTF defines the unit of distance as meters, but boom box sample asset used in the spec is 0.02 units in diameter, which would make it 2cm. That's way too tiny for a boom box. The inconsistent conventions leads me to believe that the person who wrote section 3.4 of the GLTF spec, and made the boom box, was not communicating correctly with the writers of the other parts of the spec. Or maybe it was ruined by a committee settling on an inconsistent compromise. Out of curiosity, I also checked how Blender defines cameras. They... point down by default. Interesting choice. Godot is self-consistent, the rest of the world is not. So now we have to add compatibility options. ¯\_(ツ)_/¯ |
I think what's important for Godot is to add ease of use, and rotating all your models 180degrees and adding a pivot is something that (imo) Godot could take care of, since it's something that's consistently a hassle across 3D projects. |
|
After a lengthy discussion with other maintainers, it is clear that this issue is not as simple as it appear. Thanks to @aaronfranke 's attempt at a rotation, i think it's obvious why just rotating the object doesn't work. Importer maintainers have voiced their concern over adding complexity to the importer by adding extra rotations, and other maintainers have voiced concern over possibly adding extra convetions or look_at methods and so on. It's clear to us that this is an involved discussion that needs to happen in a moment that does not have a massive release coming which is already in feature freeze. To the people experiencing this as an issue: please be patient. You can write your own post-import script that adds an extra node on top of the hierarchy to rotate the model. Once we settle on a solution for this, we'll update this thread. For now, there's no point in continuing the discussion. We need to take our time and gather our ideas on how to best address this in the best way possible and with the lowest impact possible on the various areas. To Godot users pitching in this thread, thanks for your feedback. It has sparked a lot of discussion and allowed us to look deeper into things that turned out to be more complex than we thought. To maintainers participating, thanks for putting your energy into this. Your input has been very valuable and allows people reading to understand the complexity of the topic at hand. |
|
Sigh, I really wish this was never changed in the first place, since it worked fine in early 3.x versions. People can argue semantics about the which way front is based on the axis, but having a front view should adhere to the way it works in every other 3d package out there. I have used most 3d packages over the years and regardless of their worldspace up axis, they all have the front view based on what you see in the top view. If a character in the top view is looking down (in screen space), then this is the direction that the front camera should be looking towards. As can be seen from this screenshot in blender. I have put the arrow in to indicate this direction. This is what artists expect and is the way that most people would model and rig a character. It doesn't matter if it is a y-up or z-up package or negative/positive in the view direction.
I currently have my front hotkey mapped to rear in godot, so I have learned to just ignore what the godot viewport label says. The best way of solving this issue is to make an option in the preferences so that front view can be set to either positive or negative z direction. Surely, this would keep everyone happy? Having an option to rotate 180 degrees on import is just going to cause more confusion and is an attempt to correct a bad default. Most Godot users are going to model their assets in Blender, Maya or Zbrush and they all adhere to what I describe above. |
Was it different in 3.0? I think models have always been facing +z |
|
@QbieShay not sure as I was using dae back then. What I am referring to is the way that the front ortho camera works in Godot which has changed since then. It used to be consistent with the way Blender or Maya, etc worked. As far as i can tell, the OP is having issues with what front ortho looks like in Godot, as it is the reverse of the conventional way (as used by blender). The model has been imported (presumably) correctly into Godot, but the Godot front camera is what a rear camera is doing in Blender. This is why I was suggesting having a settings option to orientate the front ortho camera in Godot to be the same as Blender. This way the front camera is consistent between Blender and Godot and is what most artists would expect. |
|
A short summary of PRs working on fixing this problem in different ways: From @aaronfranke:
From @TokageItLab:
From @reduz:
|
|
Just confirming that I'm another user experiencing this issue (sorry for any spam). Is there a workaround for now? |
|
@des1redState A workaround is to parent your model to an empty Spatial and rotate said empty spatial to however you want |
|
All PRs addressing this issue have been either merged or closed, and as far as I know all engine developers are satisfied with the current state. Therefore, I am closing this PR as resolved. 🎉 In addition to the list of engine PRs I made above, the 3D asset direction conventions have been documented on the Importing 3D scenes page. This page describes briefly, but dense with detail, how local and global directions work in Godot, Blender, and GLTF. I have some closing notes to hopefully help clarify things. Much of this is focused on terminology and is redundant with the documentation. Pay attention to the terminology: "forward" vs "front".
|
|
New to Godot (4.2.2) and totally confused about axes. Which one does "Front View" translate to? I'd normally think it's the latter, but people saying front is -Z makes me think the former definition is true. Up is down, left is right I suppose. |
|
"Forward" is an azimuth and "Front" is a side of the surface. Forward indicates the direction in the global space and is -Z. In this case, Camera forward and Light forward are -Z because the direction of the camera and lights conform to space. On the other hand, in OpenGL's right-hand coordinate system, the model is defined as facing the camera, so Model front is +Z. See also https://docs.godotengine.org/ja/4.x/classes/class_vector3.html#class-vector3-constant-forward. Then, "Front View" can be expressed as "a view that allows the user to see the front side of the model". Edit from aaronfranke: Fix front/forward mixup, it can be confusing even for experienced devs. |
|
I selected a few different nodes and I always got the same view from "Front View", so it's model-independent aka a global thing. On that basis, it should've been named "Forward view" albeit, still weird, since it looks from the front to the back by default, contrary to what a normal human would consider "Forward". |
|
It is certainly model-independent, and one that can look front side of the model when the model is placed at global origin with initial basis. This allows the user to notice when the user has imported the model in the wrong orientation. Front View is also a convention, and Blender and others have adopted the name Front View. Well, BTW, I think it would be fine to make a proposal to implement something like Model Front View in Godot. |
|
I noticed this and I think @romlok has a good point. On that note, I believe if current views are to remain to global/model-indepedent, they should adhere to the naming used here. Therefore, and to polish @romlok's idea, if "Front view" is to become "Look Forward", then "Top view" has to become "Look Down", "Bottom view" -> "Look Up", "Rear view" -> "Look Back", "Left" -> "Look Right", and "Right view" -> "Look Left". Essentially, naming based on the vector of the view. The simple change of labels from the noun "view" to a verb "Look" helps a ton in avoiding any confusion, especially for the cases of right, left and back. Of course changing the views to be model-dependent is also an option. P.S. Would be great to change "Back" to "Backward" in here to align it better with "Forward" and avoid any possible confusion with its interpretation as "rear" in colloquial English. |
|
There should be no chance to rename the View, as it would be inconsistent with other DCC software and more confusing; Do you make suggestions that for other DCC software too? It is also unnatural as a word. "View forward" is understandable (although that is not a noun), but "Forward view" is strange. Well, I have not seen any software that adopts it. It might be appropriate as a function name, but not as an enum. Given the colloquial explanation in any tutorial or document, it should be a noun. Changing BACK to BACKWARD might be a good point (then, LEFT and RIGHT should also be LEFTWARD and RIGHTWARD), but that is all. |
|
My last edit was before your reply, so I wonder if you replied from an email. Anyhow, I suggest you re-read my comment. As for other softwares, I won't comment if they have such discrepancies in their usage of terminology as in Godot that needs to be fixed. |
That would also imply UP becomes UPWARD and DOWN becomes DOWNWARD. I'm in favor of using simpler names when possible. We only use "Forward" because "Fore" isn't a common English word. |
|
I mentioned that as P.S. because it wasn't that important, though certainly an improvement. |
Describe the project you are working on
A 3D Game.
Describe the problem or limitation you are having in your project
The GLTF specification says:
Which, for some reasons, contradicts Godot, which recommends that -Z be the forward direction.
In blender, if I have a character set up the conventional way:
Front view with -Y forward
I export it as gltf and import it into godot, my character is facing the wrong way.
Front camera is showing the back of my character (he is looking towards +Z)
This is what I found about GLTF decision:
This is not a discussion about which convention is the "right one".
Changing the Z direction (or any other axis) in the editor has already been discussed multiple times and rejected. This is a core design decision of Godot.
I don't want to manually flip all my characters so that they are facing the right way in Godot.
The vast majority of 3D tools with GLTF export will consider +Z as the forward direction.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
I suggest adding an import option for GLTF, FBX and blend files (they are all essentially importing GLTF) that allows users to flip the meshes and skeletons by 180° around the Y axis.
It should be convenient for users to use this as the default for all 3D imports.
Maybe this should even be the default behavior, otherwise meshes will be facing backwards most of the time.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
A checkbox in the importer labelled "-Z is forward (godot convention)" or something like that.
If this enhancement will not be used often, can it be worked around with a few lines of script?
One could write a custom import script that flips the root node.
But I think it is a question of having good defaults: using any model generated by 3D tools that export to GLTF will face backwards in the editor.
Is there a reason why this should be core and not an add-on in the asset library?
This reduces confusion when people use default methods like
look_atand copy code from official tutorials, while using the vast majority of available 3D assets.The text was updated successfully, but these errors were encountered: