There is a false positive in the check of the depth with camera borders.
The fix clamps the value and set the point as interpolated.
I do some cleanups too.
Details
Details
Diff Detail
Diff Detail
- Repository
- rB Blender
- Branch
- temp-T92351 (branched from master)
- Build Status
Buildable 18044 Build 18044: arc lint + arc unit
Event Timeline
| source/blender/editors/gpencil/gpencil_paint.c | ||
|---|---|---|
| 1097–1112 | This will now basically ignore anything hit in the zbuffer with a depth less than 0.51f. In the example above, the two cubes can now not be painted on. I am not too familiar with the distribution of OpenGL depth values [on first sight I was a bit confused that a ton of the precission seems to be wasted very close to the camera? -- so in order to have values below 0.5, you have to have surfaces very close to the camera...] Then I am also unsure why the line that is drawn for the camera border gives values around 0.5? (it would at least be good to explain that "magic number" in a comment). I understand we are using the regular zbuffer for this, my impression is that a "nicer" fix would be to somehow ignore wires/lines for the surface projection alltogether (unsure how easy this would be to accomplish), just saying that atm. all sorts of wire suff will be considered (lights, lattices, forcefields, ...) which all seems wrong to me. Most of this stuff can at least be turned OFF with Overlay Extras, the camera borders in camera view cannot unfortunately. Maybe I am not the right person to review this, will add @Clément Foucault (fclem) as reviewer here. | |
Comment Actions
regarding the camera border being drawn in the zbuffer: for some reason this cannot be excluded with Overlay > Extras, however if Overlays are disabled completely, this bug will not occur anymore
Comment Actions
Camera will always be drawn (even if Overlay > Extras are OFF) because it needs to be able to be selected, see comment:
/* Show if this is the camera we're looking through since it's useful for selecting. */
So a bit out of ideas (without spending more time on this), not sure if it would be possible to check the selection buffer as well and exclude e.g. the active camera that way? Can something be valid in the selection buffer but still be excluded from zBuffer @Clément Foucault (fclem) (pretty much on shaky ground here)?
Comment Actions
@Philipp Oeser (lichtwerk) I totally agree with you that this is hack and we must avoid it. I just did the patch to demostrate the failure of ED function. The point is why this function is returning this 0.5 value.
Comment Actions
Cleaning up my review queue (I usually dont do review).
Not sure if this will still progress, but seems there is not much that I can do.