Skip to content
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

Matrix Transforms don't work correctly. #1228

Closed
Feral3d opened this issue Jun 20, 2020 · 14 comments
Closed

Matrix Transforms don't work correctly. #1228

Feral3d opened this issue Jun 20, 2020 · 14 comments

Comments

@Feral3d
Copy link

Feral3d commented Jun 20, 2020

In UPBGE version 2.5 & 2.5a, attempting to assign a matrix transform to a game object fails to assign the correct scale.

Instead it appears to assign the adjugated() Matrix to the scale of the object.

Test the attached *.blend file to see the error:

https://www.dropbox.com/s/315ucajbabss2px/Test.blend?dl=0

On a personal note. Thank you.
UPBGE is wonderful!
image

@youle31
Copy link
Collaborator

youle31 commented Jun 20, 2020

you can try:

if sensor.status == 1: #instead of if sensor.positive

Else, I think it is a bit weird to assign a scale matrix to the WorldTransform directly.
I'd do: own.worldTransform = own.worldTransform * scaleMatrix

@Feral3d
Copy link
Author

Feral3d commented Jun 20, 2020

@youle31 thank you for the interesting input!
1)
sensor.positive == 1. Is this somehow more efficient?
2)
The Matrix that is being applied in this test is not a "scale matrix', it is a 4x4 transform matrix.
Your suggestion own.worldTransform = own.worldTransfrom*scaleMatrix still results in the same incorrect result.
3)
Being able to directly input Transfoms directly is weird? I felt that this is the best way to store an objects location,rotation and scale? Is there more sensible way to do this?

@BluePrintRandom
Copy link
Member

in upbge 0.3.0 it's working correctly @youle31 I am not sure what changed

@lordloki
Copy link
Member

This is because 0.2.5 uses another math library. I will check it

@Feral3d
Copy link
Author

Feral3d commented Jun 20, 2020

@lordloki 🙏 If it is of any help:
When I try to set the transform to a specific matrix, the object's transform matrix is set to the adjugated() matrix rather than the matrix itself.

To get the original matrix back:
Fixed_matrix = Matrix.adjugated ()* matrix.inverse ()

My suspicion is that the matrix is being applied to both local and global Transforms at the same time.
This is resulting in a matrix*matrix like problem?

@youle31
Copy link
Collaborator

youle31 commented Jun 20, 2020

@Feral3d : I advised to use:

if sensor.status == 1: #instead of if sensor.positive

sensor.status == 1, not sensor.positive == 1.

@youle31
Copy link
Collaborator

youle31 commented Jun 20, 2020

ok, i saw the bug...

@lordloki
Copy link
Member

Some more info:
This is caused by some commit between 0.2.2 and 0.2.3. I think the most probably one is the moto to mathfu replacement.
The issue is not in the matrix creation is in the matrix asignning.
image

@Feral3d
Copy link
Author

Feral3d commented Jun 22, 2020

Yes @lordloki you are 100% correct. Everything seems fine until I assign the Matrix directly to the world or local transform.

@lordloki
Copy link
Member

lordloki commented Jun 22, 2020

The issue is in KX_GameObject::pyattr_set_worldTransform
exactly in the rotation matrix as it should be:
1.0, 0.0, 0.0
0.0, 1.0, 0.0
0.0, 0.0, 1.0
and it is
0.75, 0.0, 0.0
0.0, 0.75, 0.0
0.0, 0.0, 0.75

I will fix tomorrow or tomorrow after.
localTransform has the same issue

@Feral3d
Copy link
Author

Feral3d commented Jun 23, 2020

Thank you @lordloki x (10, 10, 10)

@lordloki
Copy link
Member

Fixed in 0.2.5 branch.
image

Here you have a build including the fix: https://mega.nz/file/F4d3QC7K#s5h4qzBsMucvN3ttsHrz97mNepPWYLzBV7Lirq4ODSg

Thanks for reporting.

@youle31
Copy link
Collaborator

youle31 commented Jun 23, 2020

Great! Thanks very much lordloki!

@Feral3d
Copy link
Author

Feral3d commented Jun 23, 2020

Thank you so much @lordloki !! You are a life-saver!
0,.....,o

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants