Maniphest T80214

Project from View broken
Closed, ArchivedKNOWN ISSUE

Assigned To
Campbell Barton (campbellbarton)
Authored By
Sean Kennedy (hype)
Aug 29 2020, 7:01 AM
Tags
  • BF Blender
  • Modeling
Subscribers
Campbell Barton (campbellbarton)
Philipp Oeser (lichtwerk)
Richard Antalik (ISS)
Sean Kennedy (hype)
Sergey Sharybin (sergey)

Description

System Information
Operating system: Win7
Graphics card: Titan X

Blender Version
Broken: 2.83.2
Worked: not sure

When using Project from View to texture some simple geometry with an image, vertices that are somewhat far away or behind the camera (or some unknown threshold) do not project correctly.

Create geometry where some of the geometry stretches far out of camera view, or is angled behind the camera.

The attached file is a very simple scene with a project from view unwrap, and one vertex has gone a little crazy and is in the wrong place. Instead of being far to the bottom right, it ends up far to the upper right.

blend file with packed image

Related Objects

Mentioned In
T80673: Remesh Resolution strange behaviour (Shift-R)
rBM7334: Add "Known Limitation" for projecting geometry behind the view
D8866: Fix T80673: Edit voxel size text flipped with some objects
Mentioned Here
rBM7334: Add "Known Limitation" for projecting geometry behind the view

Event Timeline

Sean Kennedy (hype) created this task.Aug 29 2020, 7:01 AM
Sean Kennedy (hype) added a subscriber: Sergey Sharybin (sergey).
Richard Antalik (ISS) added a subscriber: Richard Antalik (ISS).Aug 31 2020, 5:41 PM

I can confirm this, but this seems like a limitation than a bug. Issue is that you are projecting vertices from behind camera. Also do you have reason adding @Sergey Sharybin (sergey) as subscriber?

You can cut your mesh like this to produce sensible UV

I was thinking, that maybe we can clip vertices behind camera like in following patch, but I don't think it would be possible to maintain correct geometry.

diff --git a/source/blender/blenlib/intern/uvproject.c b/source/blender/blenlib/intern/uvproject.c
index 00fef29587c..3e655e529da 100644
--- a/source/blender/blenlib/intern/uvproject.c
+++ b/source/blender/blenlib/intern/uvproject.c
@@ -68,8 +68,8 @@ void BLI_uvproject_from_camera(float target[2], float source[3], ProjCameraInfo
     }
   }
   else {
-    if (pv4[2] == 0.0f) {
-      pv4[2] = 0.00001f; /* don't allow div by 0 */
+    if (pv4[2] >= 0.0f) {
+      pv4[2] = -0.00001f; /* Don't allow div by 0 and clip everything behind camera. */
     }

     if (uci->do_persp == false) {
Sergey Sharybin (sergey) added a comment.Aug 31 2020, 6:16 PM

I can confirm this, but this seems like a limitation than a bug. Issue is that you are projecting vertices from behind camera. Also do you have reason adding @Sergey Sharybin (sergey) as subscriber?

The reason Sean CCed me is because I've asked so. To me it is not so obvious why some of the points behind camera are projecting wrong. It is also not something what is intuitive from the projection happening in the motion solver.

You can cut your mesh like this to produce sensible UV

This wouldn't work for VFX usages, where camera is not still and might move/rotate, and projection happens from image sequence.

I was thinking, that maybe we can clip vertices behind camera like in following patch, but I don't think it would be possible to maintain correct geometry.

For the simple case this works, but if you subdivide the mesh few times in edit mode and project form view again then the UVs are broken again.

Interesting puzzle eh :)

Richard Antalik (ISS) added a comment.Sep 1 2020, 8:37 PM

If you need clearer example, I have moved camera a bit closer to corner of one plane so you can see better the situation. Edges coming from behind camera looks like they are diverging the closer they get to camera, but in reality they are converging to one single vertex. That's why I think it is impossible to make good UV, unless one vertex can be somehow represented by more "virtual" vertices in UV editor.


Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Sep 14 2020, 6:23 PM
Philipp Oeser (lichtwerk) added a subscriber: Philipp Oeser (lichtwerk).
In T80214#1005908, @Richard Antalik (ISS) wrote:

I can confirm this, ...

Please do so :)

Bastien Montagne (mont29) changed the subtype of this task from "Report" to "Bug".Oct 15 2020, 11:41 AM
Bastien Montagne (mont29) added a project: Modeling.
Bastien Montagne (mont29) moved this task from Backlog to Bugs (Mesh) on the Modeling board.Oct 15 2020, 5:09 PM
Campbell Barton (campbellbarton) changed the subtype of this task from "Bug" to "Known Issue".Nov 4 2020, 6:05 AM
Campbell Barton (campbellbarton) mentioned this in rBM7334: Add "Known Limitation" for projecting geometry behind the view.Nov 4 2020, 6:16 AM
Campbell Barton (campbellbarton) closed this task as Archived.Nov 4 2020, 6:16 AM
Campbell Barton (campbellbarton) claimed this task.
Campbell Barton (campbellbarton) added a subscriber: Campbell Barton (campbellbarton).

Added Known limitation to docs, closing rBM7334: Add "Known Limitation" for projecting geometry behind the view

Sergey Sharybin (sergey) added a comment.Nov 6 2020, 11:38 AM

@Campbell Barton (campbellbarton) it is always a good communication to explain why something what was considered a bug all of a sudden became a known limitation. This solves confusion of reporter and everyone else who is interested in this topic. Additionally, giving more details will help future-you and everyone from the community who would want to fully solve the limitation.

As for the suggested workaround, I do not see how it helps. The "offending" vertex will still be projected to the "wrong" position. But on top of that you'll have even more vertices which are not properly mapped: