Page MenuHome

Edit mode, Clipping region, Visuals bug and editing vertices remain slow like when geometry is not hidden
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: AMD Radeon HD 7600M Series ATI Technologies Inc. 4.5.13417 Core Profile Context 0

Blender Version
Broken: version: 2.80 (sub 51), branch: master, commit date: 2019-03-20 16:33, hash: rBb6d1946c2e6b
Worked: (optional)

Short description of error
Edit mode, Clipping region, Visuals bug and editing vertices remain slow like when geometry is not hidden

Exact steps for others to reproduce the error

  • 1 create a sphere and subdivide it many times until the model becomes heavy to edit
  • 2 clipping region a part of the geometry and you will see the visual bug
  • 3 try editing the non-hidden geometry and you will notice that it continues to be slow as if the rest of the geometry had not been hidden.

Event Timeline

Not sure if this is by design. But proportional editing appears to be able to change the mesh outside of the clipped region (Alt+B), unlike with hidden vertices (H, Alt+H).

To reproduce the visual bug, I had to hide (H) half of the sphere first, then clip (Alt+B) to a visible quarter. This lead the previously not hidden quarter to be partially visible outside of the clipped region.

in my case I just need to press Clipping region ...
but I think it's due to the fact that my gpu is part of the workarounds-gpu's

anyway, what matters to me much more is the fact that even with clipping region the geometry continues to be difficult to edit on heavy models ... and if it stays that way, this function is practically useless

I can't reproduce the visual bug with by just open the file, so I guess that part is a EOL GPU bug.

@matc (matc) what GPU do you have?

The clipping plane is not for speeding up mesh operators. It for speeding up drawing (or simply hiding objects) in the viewport by not rendering them.
So the only thing that is a bug here is the visual part.

The file does not have the bug for me by default either.

@Sebastian Parborg (zeddb) RX 580. I don't think its hardware related. It looks like there is a different shader used for the parts outside of a partially clipped mesh.

Hiding parts of the mesh is not the problem here. If there are no hidden parts the outline is still showing.

Edit mode:

Object mode:

Another thing I noticed is when moving a partially clipped object in Rendered mode. This is probably the only unintentional thing here.

The clipping plane is not for speeding up mesh operators. It for speeding up drawing (or simply hiding objects) in the viewport by not rendering them.
So the only thing that is a bug here is the visual part.

ok i checked and the same thing happens on blender 2.79 ... but too bad ...
because if I select the piece of geometry that I am interested in editing, if I press the shortcut "p" to separate the geometry, that piece immediately becomes light as a feather ...
so I ask and I suggest you guys ..
@Clément Foucault (fclem)
@Germano Cavalcante (mano-wii)
it would be too complex conceptually a thing, if during "the phase of moving vertices" until the end of the operation:
to automatically separate a piece of geometry of a slightly larger area than the vertices being edited making it a separate object, and then make a "join" and a "merge vertex/remove doubles" at to finished editing operation"

I can't reproduce the visual bug with by just open the file, so I guess that part is a EOL GPU bug.

try to open the file with "load UI" option actived

Still can't seem to reproduce this on my end.

@Sebastian Parborg (zeddb) This has been fixed with 7454fa927b80118 and 106551b9ad1f12. Clipping does not look like it's implemented in a way that would enhance performance.

This would be the only remaining bug in this thread.


Steps to reproduce

  1. Open default .blend
  2. Switch to "Rendered" shading
  3. Select a clipping region (size and position are irrelevant)
  4. Rotate the viewport, the "Cube" appears to be producing some sort of traces when in motion.

@matc (matc) I can not reproduce that either. So I'm guessing this is driver related.

@Clément Foucault (fclem) can you reproduce these artifacts?

@Sebastian Parborg (zeddb) Does clipping work properly for you in Rendered?

@matc (matc) the rendered object is not clipped (known limitation), but I do not get the rendering artifacts you describe.

On linux it looks good for me too.

I downloaded the latest build blender-2.80-adfdae3fc2f4-win64
the bug has remained unchanged , at this point, I think it was only fixed for the non-workaround gpus

Without this line my artifacts disappear.

diff --git a/source/blender/draw/engines/eevee/shaders/lit_surface_vert.glsl b/source/blender/draw/engines/eevee/shaders/lit_surface_vert.glsl
index 141d3363a09..043a7b757f3 100644
--- a/source/blender/draw/engines/eevee/shaders/lit_surface_vert.glsl
+++ b/source/blender/draw/engines/eevee/shaders/lit_surface_vert.glsl
@@ -71,7 +71,6 @@ void main()
 #endif
 
 	/* Used for planar reflections */
-	gl_ClipDistance[0] = dot(vec4(worldPosition, 1.0), ClipPlanes[0]);
 
 #ifdef USE_ATTR
 	pass_attr(pos);

Sebastian Parborg (zeddb) lowered the priority of this task from Needs Triage by Developer to Normal.