Grease pencil: Reproject strokes bad behavior when used in orthographic free navigation. #88313

New Issue

Samuel Bernou · 2021-05-15T19:38:32+02:00

Samuel Bernou commented

2021-05-15 19:38:32 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30

Blender Version
Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-14 16:16, hash: d4a36c7ad5
Worked: (newest version of Blender that worked as expected)

Short description of error
When reprojecting on surface in free navigation + orthographic mode, the strokes are traversing the mesh and stopping on back instead of front.
note : In ortho-camera the reproject works correctly.
Inverting mesh normals doesn't seem to affect anything.

Exact steps for others to reproduce the error

Open attached blend 01
01_reproject_surface_in_ortho_view.blend

In free navigation and othographic view
in grease pencil edit > right-click > reproject > Surface

After meddling a bit with my file, trying to invert mesh normals and other thing I sadly cannot remember to reproduce, I got another weird error. In the same configuration the reprojection just doesn't do anything -> see "bugged" file 02
02_bugged__no_reproject_surface_in_ortho.blend

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 457.30 **Blender Version** Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-14 16:16, hash: `d4a36c7ad5` Worked: (newest version of Blender that worked as expected) **Short description of error** When reprojecting on surface in free navigation + orthographic mode, the strokes are traversing the mesh and stopping on back instead of front. note : In ortho-camera the reproject works correctly. Inverting mesh normals doesn't seem to affect anything. ![otho_free_view_project_on_back.png](https://archive.blender.org/developer/F10108957/otho_free_view_project_on_back.png) **Exact steps for others to reproduce the error** Open attached blend `01` [01_reproject_surface_in_ortho_view.blend](https://archive.blender.org/developer/F10108948/01_reproject_surface_in_ortho_view.blend) 1. In free navigation and othographic view 2. in grease pencil edit > right-click > reproject > Surface After meddling a bit with my file, trying to invert mesh normals and other thing I sadly cannot remember to reproduce, I got another weird error. In the same configuration the reprojection just doesn't do anything -> see "bugged" file `02` [02_bugged__no_reproject_surface_in_ortho.blend](https://archive.blender.org/developer/F10108951/02_bugged__no_reproject_surface_in_ortho.blend)

Samuel Bernou commented

2021-05-15 19:38:32 +02:00

Added subscriber: @Pullup

Antonio Vazquez commented

2021-05-17 16:33:01 +02:00

Added subscribers: @lichtwerk, @antoniov

Antonio Vazquez commented

2021-05-17 16:33:01 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Antonio Vazquez commented

2021-05-17 16:33:01 +02:00

@lichtwerk Could you help here? The problem is in ED_gpencil_stroke_reproject() function when the mode is Surface (line 1278). I had this code with the old method of the reprojection (used in Draw mode), but it was changed to use ED_transform_snap_object_project_ray() function, but I have no idea how works this function and why it is doing the reprojection in the back of the surface.

@lichtwerk Could you help here? The problem is in `ED_gpencil_stroke_reproject()` function when the mode is Surface (line 1278). I had this code with the old method of the reprojection (used in Draw mode), but it was changed to use `ED_transform_snap_object_project_ray()` function, but I have no idea how works this function and why it is doing the reprojection in the back of the surface.

Philipp Oeser commented

2021-05-17 17:56:49 +02:00

Added subscriber: @mano-wii

Philipp Oeser commented

2021-05-17 17:56:49 +02:00

Not sure if this is the "fault" of ED_view3d_win_to_ray (ED_view3d_win_to_vector specifically), or rather ED_transform_snap_object_project_ray (and friends) -- if you negate the ray normal in ortho, all is fine.

note: this was swapped in f54ed9f5e0

Got to go now, can dig deeper tomorrow, maybe @mano-wii knows right away?

Not sure if this is the "fault" of `ED_view3d_win_to_ray` (`ED_view3d_win_to_vector` specifically), or rather `ED_transform_snap_object_project_ray` (and friends) -- if you negate the ray normal in ortho, all is fine. note: this was swapped in f54ed9f5e0 Got to go now, can dig deeper tomorrow, maybe @mano-wii knows right away?

Germano Cavalcante commented

2021-05-17 20:02:14 +02:00

As far as I can see the ray_start is located inside the object. Thus the points are projected on the first surface that it finds. (i.e, the other side of the mesh).
If ray must start from the clip_min, the function that should be called is ED_view3d_win_to_ray_clipped instead of ED_view3d_win_to_ray.
But I suppose the ray must start from the point of GPencil.
If so, use the coordinates of the GPencil as ray_start:

diff --git a/source/blender/editors/gpencil/gpencil_utils.c b/source/blender/editors/gpencil/gpencil_utils.c
index 9fba2ce5902..04764587ebe 100644
--- a/source/blender/editors/gpencil/gpencil_utils.c
+++ b/source/blender/editors/gpencil/gpencil_utils.c
@@ -1276,7 +1276,6 @@ void ED_gpencil_stroke_reproject(Depsgraph *depsgraph,
     }
     else {
       /* Geometry - Snap to surfaces of visible geometry */
-      float ray_start[3];
       float ray_normal[3];
       /* magic value for initial depth copied from the default
        * value of Python's Scene.ray_cast function
@@ -1285,13 +1284,14 @@ void ED_gpencil_stroke_reproject(Depsgraph *depsgraph,
       float location[3] = {0.0f, 0.0f, 0.0f};
       float normal[3] = {0.0f, 0.0f, 0.0f};
 
-      ED_view3d_win_to_ray(region, xy, &ray_start[0], &ray_normal[0]);
+      ED_view3d_win_to_vector(region, xy, &ray_normal[0]);
+      BLI_assert(gps->flag & GP_STROKE_3DSPACE);
       if (ED_transform_snap_object_project_ray(sctx,
                                                depsgraph,
                                                &(const struct SnapObjectParams){
                                                    .snap_select = SNAP_ALL,
                                                },
-                                               &ray_start[0],
+                                               &pt2.x,
                                                &ray_normal[0],
                                                &depth,
                                                &location[0],

As far as I can see the `ray_start` is located inside the object. Thus the points are projected on the first surface that it finds. (i.e, the other side of the mesh). If ray must start from the `clip_min`, the function that should be called is `ED_view3d_win_to_ray_clipped` instead of `ED_view3d_win_to_ray`. But I suppose the ray must start from the point of GPencil. If so, use the coordinates of the GPencil as `ray_start`: ``` diff --git a/source/blender/editors/gpencil/gpencil_utils.c b/source/blender/editors/gpencil/gpencil_utils.c index 9fba2ce5902..04764587ebe 100644 --- a/source/blender/editors/gpencil/gpencil_utils.c +++ b/source/blender/editors/gpencil/gpencil_utils.c @@ -1276,7 +1276,6 @@ void ED_gpencil_stroke_reproject(Depsgraph *depsgraph, } else { /* Geometry - Snap to surfaces of visible geometry */ - float ray_start[3]; float ray_normal[3]; /* magic value for initial depth copied from the default * value of Python's Scene.ray_cast function @@ -1285,13 +1284,14 @@ void ED_gpencil_stroke_reproject(Depsgraph *depsgraph, float location[3] = {0.0f, 0.0f, 0.0f}; float normal[3] = {0.0f, 0.0f, 0.0f}; - ED_view3d_win_to_ray(region, xy, &ray_start[0], &ray_normal[0]); + ED_view3d_win_to_vector(region, xy, &ray_normal[0]); + BLI_assert(gps->flag & GP_STROKE_3DSPACE); if (ED_transform_snap_object_project_ray(sctx, depsgraph, &(const struct SnapObjectParams){ .snap_select = SNAP_ALL, }, - &ray_start[0], + &pt2.x, &ray_normal[0], &depth, &location[0], ```

Philipp Oeser commented

2021-05-18 10:47:14 +02:00

LGTM, thx checking @mano-wii

This makes sense, see the comment for ED_view3d_win_to_origin

 * \note Orthographic views have a less obvious origin,
 * Since far clip can be a very large value resulting in numeric precision issues,
 * the origin in this case is close to zero coordinate.

LGTM, thx checking @mano-wii This makes sense, see the comment for `ED_view3d_win_to_origin` ``` * \note Orthographic views have a less obvious origin, * Since far clip can be a very large value resulting in numeric precision issues, * the origin in this case is close to zero coordinate. ```

Antonio Vazquez commented

2021-05-18 15:51:49 +02:00

@mano-wii Your fix works perfect. You can commit the fix...or if you cannot do it now, I can commit setting you as Author.