-
Notifications
You must be signed in to change notification settings - Fork 79
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 handling of projective transforms #199
base: master
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -921,8 +921,8 @@ graphene_matrix_transform_point (const graphene_matrix_t *m, | |
vec3 = graphene_simd4f_init (p->x, p->y, 0.0f, 1.0f); | ||
graphene_simd4x4f_point3_mul (&m->value, &vec3, &vec3); | ||
|
||
res->x = graphene_simd4f_get_x (vec3); | ||
res->y = graphene_simd4f_get_y (vec3); | ||
res->x = graphene_simd4f_get_x (vec3) / graphene_simd4f_get_w (vec3); | ||
res->y = graphene_simd4f_get_y (vec3) / graphene_simd4f_get_w (vec3); | ||
} | ||
|
||
/** | ||
|
@@ -951,9 +951,9 @@ graphene_matrix_transform_point3d (const graphene_matrix_t *m, | |
vec3 = graphene_simd4f_init (p->x, p->y, p->z, 1.f); | ||
graphene_simd4x4f_point3_mul (&m->value, &vec3, &vec3); | ||
|
||
res->x = graphene_simd4f_get_x (vec3); | ||
res->y = graphene_simd4f_get_y (vec3); | ||
res->z = graphene_simd4f_get_z (vec3); | ||
res->x = graphene_simd4f_get_x (vec3) / graphene_simd4f_get_w (vec3); | ||
res->y = graphene_simd4f_get_y (vec3) / graphene_simd4f_get_w (vec3); | ||
res->z = graphene_simd4f_get_y (vec3) / graphene_simd4f_get_w (vec3); | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. graphene_matrix_unproject_point3d() does:
Which seems more efficient than this There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good point. Also interesting that graphene_matrix_unproject_point3d takes two matrices - I get the sense that we are not fully understanding the graphene api and are not using it properly in gtk There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unprojection requires the viewport, and has a split modelview/projection matrices because most users of such an API will have a separate modelview and projection matrices already. I guess the issue, here, is that Graphene adheres to a different set of conventions. The documentation should clarify the use cases. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In 3d apps, the scene graph typically converts objects into camera space, which is a 3d space with the cameras location at origin, looking down -z axis. Then the camera projection matrix is applied on top of that to convert to 2d space. The exact transform there depends on the camera (i.e. perspective or orthonormal, field of vision, etc). When rendering an object we combine all these matrixes into one (object -> world -> camera -> screen) which the GPU applies to each object vector. However, for unproject we want to go backwards into world space (not object space), so we invert the camera->screen and apply the camera->world matrix on top of that. These are taken as two separate args because those are the two matrixes that the client usually stores, and we can't use the combined matrix because that is from object space (and only available during rendering). For gtk+, I don't really think we need unprojection, because we don't set up a complicated projection anyway. It just maps the z=0 plane one-to-one. I guess that means the exact z perspective behaviour is just what happens to fall out of the math... Maybe worth looking at. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We are handling 4x4 matrices here that operate on points in homogeneous coordinates, to go from homogeneous coordinates to points with 3 coordinates (or 2, as the transform_bounds api does) in general requires a division by w, otherwise the results are just wrong. Given that this api is in use, we should probably just document the fact that passing a matrix with perspective component to transform_bounds and transform_points is going to yield unexpected results. For GTK, I have added the functions we needed here: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gsk/gsktransform.c#L2169 |
||
|
||
/** | ||
|
@@ -1034,9 +1034,9 @@ graphene_matrix_transform_bounds (const graphene_matrix_t *m, | |
graphene_point_t __p; \ | ||
graphene_rect_get_ ## corner (rect, &__p); \ | ||
__s = graphene_simd4f_init (__p.x, __p.y, 0.f, 1.f); \ | ||
graphene_simd4x4f_vec4_mul (&matrix->value, &__s, &__s); \ | ||
out_p.x = graphene_simd4f_get_x (__s); \ | ||
out_p.y = graphene_simd4f_get_y (__s); } while (0) | ||
graphene_simd4x4f_point3_mul (&matrix->value, &__s, &__s); \ | ||
out_p.x = graphene_simd4f_get_x (__s) / graphene_simd4f_get_w (__s); \ | ||
out_p.y = graphene_simd4f_get_y (__s) / graphene_simd4f_get_w (__s); } while (0) | ||
|
||
TRANSFORM_POINT (m, &rr, top_left, ret[0]); | ||
TRANSFORM_POINT (m, &rr, top_right, ret[1]); | ||
|
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.
copy/paste bug here I think.