-
-
Notifications
You must be signed in to change notification settings - Fork 21.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sample_baked_with_rotation gives wrong transform #78361
Comments
Will look into it, yes, it seems to flip the axes It does work correctly with a |
It appears the transform returned from the target.position = tx.get_origin()
target.rotation = tx.get_rotation() I'm unsure why it is using this unconventional format, but changing it would break compatibility so best to just clarify in the documentation. Will fix the documentation |
I'm not sure what you exactly mean. The negative y-scale in transform seems to be the culprit or bug here... print(tx.get_scale()) I.e. this works as expected:
|
I mean no that gives a different result than the behaviour of The returned transform is: If you create a curve of the points "Forward" isn't a thing in the 2D coordinates but one would expect it to be the X-axis, otherwise a curve would be very strange to use no? If you want a character to move along a circular curve shouldn't it be facing normally at the top of that curve? Considering how this code was directly moved from One can argue that this convention is confusing and harmful, but changing it would not be possible at this time, so documenting it and clarifying how it's made up is the best way |
I haven't had time to read/decipher the corresponding code. Other practical question, why it here manipulates the scale of the target transform at all? |
This is as I said because it swaps the X and Y axes, meaning that it no longer follows the left hand convention, by default the Y axis is 90 degrees clockwise of the X axis, but in this case it is counter clockwise, because of the swapped axes, the scale is extracted in a way that assumes the left hand convention Remember that |
Thanks a lot. I'm starting to not know what my left and right hands are in the matrix. 🔃 🔁 🔄 Godot obviously prefers 3D and 2D objects from behind :) Personally, I would rather break whatever compatibility and fix it once forever ... |
No problems! I had a hard time getting my head around it for a while, and my right wrist is all sore from trying to work out the left and right hand rules, note that 3D in Godot is right hand, but 2D is left hand, very confusing Unfortunately we can't do that, at least not for some time, I suspect not until 5.0 as it's an easy thing to resolve with documentation clarification, and doesn't break anything, as long as you compensate for it, you don't really need the whole transform anyway as it doesn't scale or skew, we could just return a See if the documentation update in the linked PR is clear to you if you wouldn't mind |
I just tried the PathFollow2D Node and it indeed does what I expected to do. I guess I didn't try it because I was focused on the text transform effect PR. I think we should just make this function just return a good transform and match the behavior of PathFollow2D. I get the idea of using a Transform2D and then reading Y and X axis as forward and right, but the convenience of just using the transform to slap it into some visual element is too good to let it pass. I like that PathFollow2D chooses X+ for forward. It is my preferred way of solving the problem. It makes it seamless to integrate with the work I did in the linked PR for flowing the text over a path. I think that, given the use case is currently broken, and the docs previously had no suggestion on how to use this. I feel we should do an appropiate fix now instead of documenting the quirkiness of current implementation. I can do a PR later today or tomorrow with my suggested fix. |
The docs did have the proposal yes, this: var transform = curve.sample_baked_with_rotation(offset)
position = transform.get_origin()
rotation = transform.get_rotation() This is a compatibility breaking change so I don't think it's going to be merged any time soon, at the very earliest for 4.2, I do not agree that this is a bug necessarily, but a quirk in the implementation, we could fix it eventually, but the already present suggestion, and clarification, is better than a compatibility breaking change here And if this quirk was not known, why would the example of how to use it be included? Sounds strange to assume that the user doesn't know how to use a |
Also you mean that fixing the sample_baked_with_rotation output transform would break something else? diff --git a/scene/resources/curve.cpp b/scene/resources/curve.cpp
index 12ee36654d..bf3256a9c3 100644
--- a/scene/resources/curve.cpp
+++ b/scene/resources/curve.cpp
@@ -1025,6 +1025,8 @@ Transform2D Curve2D::sample_baked_with_rotation(real_t p_offset, bool p_cubic) c
// 2. Sample rotation frame.
Transform2D frame = _sample_posture(interval);
frame.set_origin(pos);
+ frame.set_scale(Vector2(-1.0, 1.0));
+ frame.set_rotation(frame.get_rotation() + Math_PI);
return frame;
} |
It would break anyone's code that uses it, it would of course have to be adjusted in the code, like The change would instead be in the return Transform2D(side, forward, Vector2(0.0, 0.0)); To: return Transform2D(forward, side, Vector2(0.0, 0.0)); godot/scene/resources/curve.cpp Lines 977 to 981 in a83eb16
The fact here IMHO is that this code, while strange, is not unusable, you just have to follow the instructions (including the current ones in the documentation), it's cumbersome, but it's not broken, just strange, to me that means that making changes that actually breaks people's code is a bad idea |
If it breaks the use case (see in the Minimal reproduction project) , I doubt someone will actually copy the transform to the target directly? |
It isn't broken, it's just weird, you can use it fully, it being broken would mean it wouldn't return anything useable I'd argue The people who follow the current instructions in the documentation would have their code no longer working |
This comment was marked as outdated.
This comment was marked as outdated.
Realized that I had misinterpreted how it was used here, so changed the description in the documentation PR, a change to how the current implementation works would be good, but I still argue it would have to be delayed with consideration for compatability breaking |
As you suggested, this does it for me - return Transform2D(side, forward, Vector2(0.0, 0.0));
+ return Transform2D(forward, side, Vector2(0.0, 0.0)); I agree that it breaks behavior for current users, but I also think that the sooner this gets fixed the better.
Why? there are many arguments in favor of this:
Arguments in favor of keeping up as forward:
In the end, if needed, rotation can be introduced by the user (although this applies both sides) Overall I think this fix is kind-of critical for good performance, because using the |
Agreed, realized that a scaling issue with the MRP caused me to fail to realize that the code as current does pointing along the path, not across it, as I thought, I was confused as to this part |
Flat-universe games people too. MRP + ship & rocket :) |
Godot version
4.0.3.stable
System information
Windows 10
Issue description
evaluating a curve's
sample_baked_with_rotation
gives wrong Transform2D:55374fd468146e8611b46b327faa6843.mp4
The texture should read A B C D correctly, you can see it flips the texture vertically
It is trying to match textures Positive Y to the path direction, and then positive x to the right of the path.
I think the two correct options would be:
I found this while working on this PR #77819
I could give a shot at fixing this during the weekend
Steps to reproduce
Just run the example project
Minimal reproduction project
PathSampleBug.zip
The text was updated successfully, but these errors were encountered: