Strokes made in Texture Paint when camera is set perpendicularly to surface do not appear. #71122

New Issue

Paul · 2019-10-26T21:47:58+02:00

Paul commented

2019-10-26 21:47:58 +02:00

System Information
Operating system:Win10/Win7
Graphics card:gtx1070/hd620

Blender Version
Broken: (2.80, 2.82.1 2019-10-26)
Worked: 2.79

Short description of error
In perspective mode when camera is set perpendicularly strokes made in texture paint mode do not appear.
Exact steps for others to reproduce the error
Create cube, uv unwrap, and texture. Go into perspective mode, position camera perpendicularly to one of cube faces. Make a stroke. It wont show up.
Rotate camera a bit and make stroke, it will appear. Looks like this gets worse if you come closer to surface.
Ive made video, pay attention to info from wacom driver about pressure on side thats the only way to know when im touching tablet.
https://youtu.be/2yZ588ad-f0
Regards.

**System Information** Operating system:Win10/Win7 Graphics card:gtx1070/hd620 **Blender Version** Broken: (2.80, 2.82.1 2019-10-26) Worked: 2.79 **Short description of error** In perspective mode when camera is set perpendicularly strokes made in texture paint mode do not appear. **Exact steps for others to reproduce the error** Create cube, uv unwrap, and texture. Go into perspective mode, position camera perpendicularly to one of cube faces. Make a stroke. It wont show up. Rotate camera a bit and make stroke, it will appear. Looks like this gets worse if you come closer to surface. Ive made video, pay attention to info from wacom driver about pressure on side thats the only way to know when im touching tablet. https://youtu.be/2yZ588ad-f0 Regards.

Paul commented

2019-10-26 21:47:58 +02:00

Added subscriber: @riceart

Paul changed title from ~~Strokes made camera is set perpendicularly to surface do not appear.~~ to Strokes made in Texture Paint when camera is set perpendicularly to surface do not appear.

2019-10-26 21:51:20 +02:00

Davis Sorenson commented

2019-10-27 16:28:57 +01:00

Added subscriber: @DavisSorenson

Davis Sorenson commented

2019-10-27 16:28:57 +01:00

Confirmed on c036db9f57ff for a UV-unwrapped cube. However, I'm unable to reproduce the problem with any other primitive. I tried with Suzanne, but rotating the viewport camera so that it was perpendicular to a face didn't cause any problems. I also tried rotating the model so that a particular face was normal to the global positive Y axis, like the face of the cube in the video in the original report. That didn't reproduce the bug either.

Confirmed on `c036db9f57ff` for a UV-unwrapped cube. However, I'm unable to reproduce the problem with any other primitive. I tried with Suzanne, but rotating the viewport camera so that it was perpendicular to a face didn't cause any problems. I also tried rotating the model so that a particular face was normal to the global positive Y axis, like the face of the cube in the video in the original report. That didn't reproduce the bug either.

Davis Sorenson commented

2019-10-27 16:29:10 +01:00

Removed subscriber: @DavisSorenson

Germano Cavalcante commented

2019-10-30 12:38:34 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2019-10-30 12:38:34 +01:00

Please provide a .blend file with the position saved for us to investigate.

It may well be related to the problem identified in #70128 (although it has no vertices behind the viewport).

Please provide a .blend file with the position saved for us to investigate. It may well be related to the problem identified in #70128 (although it has no vertices behind the viewport).

Paul commented

2019-10-30 12:45:36 +01:00

In #71122#803250, @mano-wii wrote:
Please provide a .blend file with the position saved for us to investigate.

It may well be related to the problem identified in #70128 (although it has no vertices behind the viewport).

added
bug.blend

ps. it was made with 2.80.75
ps2. and i can confirm that this but exists on linux version to.

> In #71122#803250, @mano-wii wrote: > Please provide a .blend file with the position saved for us to investigate. > > It may well be related to the problem identified in #70128 (although it has no vertices behind the viewport). added [bug.blend](https://archive.blender.org/developer/F7872122/bug.blend) ps. it was made with 2.80.75 ps2. and i can confirm that this but exists on linux version to.

Jeroen Bakker was assigned by Germano Cavalcante

2019-10-30 13:26:47 +01:00

Germano Cavalcante commented

2019-10-30 13:26:48 +01:00

I can confirm the bug, but I can't tell if it is related to #70128
Interesting that if I delete the remaining faces the problem seems to disappear.

I can confirm the bug, but I can't tell if it is related to #70128 Interesting that if I delete the remaining faces the problem seems to disappear.

Jeroen Bakker commented

2019-12-10 14:10:13 +01:00

I don't think it is related to #70128. I think it isn't a bug at all.
In the case the Normal Falloff test is failing as no vertices are selected as no vertice really points to the camera.
It doesn't happen when Normal Falloff in the falloff is disabled.

issue is inside proj_paint_state_vert_flags_init in the else clause of if (ps->is_otho).
The math is done in object space and ignores many variables.

Code seems to be from the initial commit back in 2013.

The solution I have is to replace the perspective based implementation with the ortho one as this is better in handling these situations. Or remove the test at all when in perspective mode as it is selecting vertices to be evaluated later on. I prefer to replace it with the ortho one as perspective texture painting is more used and will have some performance benefit.

The other solution (actually fixing the issue) might need an overhaul of the system.

@ideasman42 what do you think what we should do with this issue?

I don't think it is related to #70128. I think it isn't a bug at all. In the case the `Normal Falloff` test is failing as no vertices are selected as no vertice really points to the camera. It doesn't happen when `Normal Falloff` in the falloff is disabled. issue is inside `proj_paint_state_vert_flags_init` in the else clause of `if (ps->is_otho)`. The math is done in `object space` and ignores many variables. Code seems to be from the initial commit back in 2013. The solution I have is to replace the perspective based implementation with the ortho one as this is better in handling these situations. Or remove the test at all when in perspective mode as it is selecting vertices to be evaluated later on. I prefer to replace it with the ortho one as perspective texture painting is more used and will have some performance benefit. The other solution (actually fixing the issue) might need an overhaul of the system. @ideasman42 what do you think what we should do with this issue?

Jeroen Bakker commented

2019-12-10 14:15:41 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-12-11 04:34:03 +01:00

Closed as duplicate of #42230

Campbell Barton closed this issue

2019-12-11 04:34:03 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Strokes made in Texture Paint when camera is set perpendicularly to surface do not appear. #71122