-
-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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
Fix wrong rotation matrix for orbit z velocity #84056
Conversation
I'm not an expert, but comparing to this image from Wikipedia, X and Y are also incorrect: Is this true? Or is this because of the coordinate system that we use? |
Maybe this difference is about clockwise and counterclockwise? |
I just tested on top of this PR and it seems to all work fine, so i'm not sure if matrices should change ..? |
@QbieShay What I am certain of is:
@YuriSizov Fortunately, all coordinate systems agree on rotation: X to Y around Z (not Y to X), Y to Z around X (not Z to Y), and Z to X around Y (not X to Z). This is a matter of correctness. The only tricky part is to remember if we are working with rows or columns. Usually code works with columns since it's more geometrically intuitive. I referenced this wiki page which indicates mat3 uses columns (see |
e34d528
to
ae69e1a
Compare
Thanks y'all. I think it's fixed now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See my comment above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks mostly good to me. Testing it out it seems great. I just caught one additional bug. When using disble_z, we are reading from the r
channel of the orbit_velocity_curve which means if you switch a particle system to disable z (that was orbiting in the z direction then you lose the orbit unless you use the x-channel of the texture, or you switch to a single channel texture.
I recognize there is some tension here in maintaining backwards compatibility as previously users could only use a regular CurveTexture and not a CurveXYZ texture. Further, CurveTexture allows you to only pass a red channel if you want. So we need to adjust the logic to maintain backwards compatibility and make it compatible with CurveXYZTextures
I would change the lines from:
if (tex_parameters[PARAM_ORBIT_VELOCITY].is_valid()) {
code += " orbit_amount *= texture(orbit_velocity_curve, vec2(lifetime)).r;\n";
}
To:
if (tex_parameters[PARAM_ORBIT_VELOCITY].is_valid()) {
CurveTexture *texture = Object::cast_to<CurveTexture>(tex_parameters[PARAM_ORBIT_VELOCITY].ptr());
if (texture) {
code += " orbit_amount *= texture(orbit_velocity_curve, vec2(lifetime)).r;\n";
} else {
code += " orbit_amount *= texture(orbit_velocity_curve, vec2(lifetime)).b;\n";
}
}
This maintains backwards compatibility and allows users to continue using a CurveXYZTexture
ae69e1a
to
f496187
Compare
Thanks Clay! Updated and tested. |
f496187
to
581a809
Compare
Oof, I just realized that checking the type of the texture won't update the MaterialKey as the MaterialKey only checks for the existence of the texture. So we need to add a new flag :( Here is the diff:
|
581a809
to
fd9cabd
Compare
fd9cabd
to
a764e42
Compare
Updated! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Tested locally and it works as far as I can tell.
Thanks! |
Closes #84033
Closes #84035