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.

Sign up for GitHub

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

Jump to bottom

Fix handling of projective transforms #199

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Fix handling of projective transforms #199

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a5c68a5
Fix handling of projective transforms
Sep 1, 2020
f80eb04
fixup! Fix handling of projective transforms
Sep 1, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions src/graphene-matrix.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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);
}

/**
Expand Down Expand Up @@ -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_z (vec3) / graphene_simd4f_get_w (vec3);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

graphene_matrix_unproject_point3d() does:

  inv_w = 1.f / graphene_simd4f_get_w (v);
  v = graphene_simd4f_mul (v, graphene_simd4f_splat (inv_w));

Which seems more efficient than this

Copy link
Author

Choose a reason for hiding this comment

The 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

Copy link
Owner

Choose a reason for hiding this comment

The 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.

Copy link
Contributor

@alexlarsson alexlarsson Sep 2, 2020 •
edited
Loading

Choose a reason for hiding this comment

The 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.

Copy link
Author

Choose a reason for hiding this comment

The 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


/**
Expand Down Expand Up @@ -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]);
Expand Down