Broken shadow in solid mode with GPU Subdiv #97877

New Issue

Alexander · 2022-05-05T11:36:06+02:00

Alexander commented

2022-05-05 11:36:06 +02:00

System Information

Operating system: Ubuntu 20.04
Graphics card: Geforce 230MX

Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits
Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44
version: 3.3.0 Alpha, branch: master, commit date: 2022-05-05 10:24, hash: `rB18bcd8321a68`

Blender Version
Broken: 3.1
Broken: 3.3.0 Alpha, branch: master, commit date: 2022-05-05 10:24, hash: 18bcd8321a

Short description of error
with a certain pose and Subdiv enabled on the GPU, the shadow is displayed incorrectly
with GPU Sibdiv

without gpu sibdiv

Exact steps for others to reproduce the error
open bandit_anim.blend
reports.zip
note disabling the Corrective Smooth modifier in that file seems to get rid of the issue

**System Information** ``` Operating system: Ubuntu 20.04 Graphics card: Geforce 230MX ``` ``` Operating system: Linux-5.13.0-0.rc6.45.fc35.x86_64-x86_64-with-glibc2.34.9000 64 Bits Graphics card: NVIDIA GeForce GTX 970M/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44 version: 3.3.0 Alpha, branch: master, commit date: 2022-05-05 10:24, hash: `rB18bcd8321a68` ``` **Blender Version** Broken: 3.1 Broken: 3.3.0 Alpha, branch: master, commit date: 2022-05-05 10:24, hash: `18bcd8321a` **Short description of error** with a certain pose and Subdiv enabled on the GPU, the shadow is displayed incorrectly with GPU Sibdiv ![Screenshot_20220505_123108.png](https://archive.blender.org/developer/F13053028/Screenshot_20220505_123108.png) without gpu sibdiv ![Screenshot_20220505_123130.png](https://archive.blender.org/developer/F13053030/Screenshot_20220505_123130.png) **Exact steps for others to reproduce the error** open bandit_anim.blend [reports.zip](https://archive.blender.org/developer/F13053032/reports.zip) note disabling the Corrective Smooth modifier in that file seems to get rid of the issue

Alexander commented

2022-05-05 11:36:06 +02:00

Added subscriber: @sanek2005

Alexander changed title from ~~Breken shadow in solid mode with GPU Subdiv~~ to Broken shadow in solid mode with GPU Subdiv

2022-05-05 11:49:55 +02:00

Philipp Oeser commented

2022-05-05 12:15:21 +02:00

Added subscribers: @kevindietrich, @lichtwerk

Philipp Oeser commented

2022-05-05 12:15:21 +02:00

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

Philipp Oeser commented

2022-05-05 12:15:21 +02:00

Can confirm.

CC @kevindietrich

Can confirm. CC @kevindietrich

Clément Foucault commented

2022-05-07 14:08:04 +02:00

Added subscriber: @fclem

Clément Foucault commented

2022-05-07 14:08:04 +02:00

@kevindietrich This might happen because of multiple reasons:

The mesh is not perfectly manifold and not tagged as such.
Some vertices position are not rounded to the same position for some adjacent faces.
Some adjacency infos are faulty.
The degenerate edge check (see DEGENERATE_TRIS_WORKAROUND) is falsely triggered.

That said, I get an assert (or a crash when launching in debug mode) in the opensubdiv code trying to open this file.

[Unknown/Just-In-Time compiled code] (Source inconnue:0)
OpenSubdiv::v3_4_4::Osd::GLVertexBuffer::allocate() (Source inconnue:0)
OpenSubdiv::v3_4_4::Osd::GLVertexBuffer::Create(int, int, void*) (Source inconnue:0)
blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void>::VolatileEvalOutput(blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void> * const this, const OpenSubdiv::v3_4_4::Far::StencilTable * vertex_stencils, const OpenSubdiv::v3_4_4::Far::StencilTable * varying_stencils, const std::vector<OpenSubdiv::v3_4_4::Far::StencilTable const*, std::allocator<OpenSubdiv::v3_4_4::Far::StencilTable const*> > & all_face_varying_stencils, const int face_varying_width, const OpenSubdiv::v3_4_4::Far::PatchTable * patch_table, blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void>::EvaluatorCache * evaluator_cache, void * device_context) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/eval_output.h:348)
blender::opensubdiv::GpuEvalOutput::GpuEvalOutput(blender::opensubdiv::GpuEvalOutput * const this, const OpenSubdiv::v3_4_4::Far::StencilTable * vertex_stencils, const OpenSubdiv::v3_4_4::Far::StencilTable * varying_stencils, const std::vector<OpenSubdiv::v3_4_4::Far::StencilTable const*, std::allocator<OpenSubdiv::v3_4_4::Far::StencilTable const*> > & all_face_varying_stencils, const int face_varying_width, const OpenSubdiv::v3_4_4::Far::PatchTable * patch_table, blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void>::EvaluatorCache * evaluator_cache) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/eval_output_gpu.cc:59)
openSubdiv_createEvaluatorInternal(OpenSubdiv_TopologyRefiner * topology_refiner, eOpenSubdivEvaluator evaluator_type, OpenSubdiv_EvaluatorCacheImpl * evaluator_cache_descr) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/evaluator_impl.cc:530)
openSubdiv_createEvaluatorFromTopologyRefiner(OpenSubdiv_TopologyRefiner * topology_refiner, eOpenSubdivEvaluator evaluator_type, OpenSubdiv_EvaluatorCache * evaluator_cache) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/evaluator_capi.cc:246)```

@kevindietrich This might happen because of multiple reasons: - The mesh is not perfectly manifold and not tagged as such. - Some vertices position are not rounded to the same position for some adjacent faces. - Some adjacency infos are faulty. - The degenerate edge check (see `DEGENERATE_TRIS_WORKAROUND`) is falsely triggered. That said, I get an assert (or a crash when launching in debug mode) in the opensubdiv code trying to open this file. ``` [Unknown/Just-In-Time compiled code] (Source inconnue:0) OpenSubdiv::v3_4_4::Osd::GLVertexBuffer::allocate() (Source inconnue:0) OpenSubdiv::v3_4_4::Osd::GLVertexBuffer::Create(int, int, void*) (Source inconnue:0) blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void>::VolatileEvalOutput(blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void> * const this, const OpenSubdiv::v3_4_4::Far::StencilTable * vertex_stencils, const OpenSubdiv::v3_4_4::Far::StencilTable * varying_stencils, const std::vector<OpenSubdiv::v3_4_4::Far::StencilTable const*, std::allocator<OpenSubdiv::v3_4_4::Far::StencilTable const*> > & all_face_varying_stencils, const int face_varying_width, const OpenSubdiv::v3_4_4::Far::PatchTable * patch_table, blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void>::EvaluatorCache * evaluator_cache, void * device_context) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/eval_output.h:348) blender::opensubdiv::GpuEvalOutput::GpuEvalOutput(blender::opensubdiv::GpuEvalOutput * const this, const OpenSubdiv::v3_4_4::Far::StencilTable * vertex_stencils, const OpenSubdiv::v3_4_4::Far::StencilTable * varying_stencils, const std::vector<OpenSubdiv::v3_4_4::Far::StencilTable const*, std::allocator<OpenSubdiv::v3_4_4::Far::StencilTable const*> > & all_face_varying_stencils, const int face_varying_width, const OpenSubdiv::v3_4_4::Far::PatchTable * patch_table, blender::opensubdiv::VolatileEvalOutput<OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, OpenSubdiv::v3_4_4::Osd::GLVertexBuffer, blender::opensubdiv::GLStencilTableSSBO, OpenSubdiv::v3_4_4::Osd::GLPatchTable, blender::opensubdiv::GLComputeEvaluator, void>::EvaluatorCache * evaluator_cache) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/eval_output_gpu.cc:59) openSubdiv_createEvaluatorInternal(OpenSubdiv_TopologyRefiner * topology_refiner, eOpenSubdivEvaluator evaluator_type, OpenSubdiv_EvaluatorCacheImpl * evaluator_cache_descr) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/evaluator_impl.cc:530) openSubdiv_createEvaluatorFromTopologyRefiner(OpenSubdiv_TopologyRefiner * topology_refiner, eOpenSubdivEvaluator evaluator_type, OpenSubdiv_EvaluatorCache * evaluator_cache) (/home/clement/Blender/blender/intern/opensubdiv/internal/evaluator/evaluator_capi.cc:246)```

Kévin Dietrich commented

2022-05-07 14:23:56 +02:00

@fclem I did briefly investigate this the other day and thought it would be the lines adjacency buffer that is not exactly the same as the one created with CPU subdivision. And some indices (> 1% of total) were indeed different. The GPU code is based on the same subdivision grid traversal as the CPU code to generate the final mesh so all indices/values in all buffers should be the same (I start pretty much all investigations by printing the buffers for CPU and GPU to verify that). I thought it might be because the order in which the polygons appear in the GPU case is different than the CPU case. Maybe we should do a subdivision grid traversal when building the lines adjacency buffer to ensure that it is built in the same order as for the CPU subdivision case and see if that fixes the issue. Otherwise it might be one of the cases you mention, or something else.

The assertion you got looks the same as #97737, and might be caused by different GLEW versions used for Blender and OpenSubDiv (this issue was revealed by the library update).

@fclem I did briefly investigate this the other day and thought it would be the lines adjacency buffer that is not exactly the same as the one created with CPU subdivision. And some indices (> 1% of total) were indeed different. The GPU code is based on the same subdivision grid traversal as the CPU code to generate the final mesh so all indices/values in all buffers should be the same (I start pretty much all investigations by printing the buffers for CPU and GPU to verify that). I thought it might be because the order in which the polygons appear in the GPU case is different than the CPU case. Maybe we should do a subdivision grid traversal when building the lines adjacency buffer to ensure that it is built in the same order as for the CPU subdivision case and see if that fixes the issue. Otherwise it might be one of the cases you mention, or something else. The assertion you got looks the same as #97737, and might be caused by different GLEW versions used for Blender and OpenSubDiv (this issue was revealed by the library update).

Kévin Dietrich commented

2022-05-25 16:03:39 +02:00

In #97877#1353605, @fclem wrote:
@kevindietrich This might happen because of multiple reasons:

The mesh is not perfectly manifold and not tagged as such.

The lines adjacency extraction tags the data and cache as non-manifold for both with and without subdivision.

Some adjacency infos are faulty.

There were differences in the output lines adjacency data. For GPU subdivision we always split quads into triangles using (0, 1, 2)/(0, 2, 3) indices, because we can't check the triangles geometry on the CPU side as the position are on the GPU at this point. For the CPU, the MLoopTri will sometimes split using (0, 1, 3), (1, 2, 3) (see Flip out of degenerate 0-2 state in mesh_tesselate.c). This concerns 6 quads in this bug report file. However, turning off this detection so that the adjacency data is generated in the same way for with and without GPU subdivision did not cause drawing issues when GPU subdivision is off, so I would guess this does not make a difference, and the observed difference in adjancency infos is not at fault here.

The degenerate edge check (see DEGENERATE_TRIS_WORKAROUND) is falsely triggered.

Removing the check in the shader did not solve the issue (I guess if it is falsely triggered, then removing the check should make a difference).

The only thing I did not try is this, because I am not what that means here or how to check:

Some vertices position are not rounded to the same position for some adjacent faces.

> In #97877#1353605, @fclem wrote: > @kevindietrich This might happen because of multiple reasons: > - The mesh is not perfectly manifold and not tagged as such. The lines adjacency extraction tags the data and cache as non-manifold for both with and without subdivision. > - Some adjacency infos are faulty. There were differences in the output lines adjacency data. For GPU subdivision we always split quads into triangles using (0, 1, 2)/(0, 2, 3) indices, because we can't check the triangles geometry on the CPU side as the position are on the GPU at this point. For the CPU, the MLoopTri will sometimes split using (0, 1, 3), (1, 2, 3) (see `Flip out of degenerate 0-2 state` in `mesh_tesselate.c`). This concerns 6 quads in this bug report file. However, turning off this detection so that the adjacency data is generated in the same way for with and without GPU subdivision did not cause drawing issues when GPU subdivision is off, so I would guess this does not make a difference, and the observed difference in adjancency infos is not at fault here. > - The degenerate edge check (see `DEGENERATE_TRIS_WORKAROUND`) is falsely triggered. Removing the check in the shader did not solve the issue (I guess if it is falsely triggered, then removing the check should make a difference). The only thing I did not try is this, because I am not what that means here or how to check: > - Some vertices position are not rounded to the same position for some adjacent faces.

Kévin Dietrich commented

2022-05-27 17:05:57 +02:00

Simplified file: bandit_anim.blend

Simplified file: [bandit_anim.blend](https://archive.blender.org/developer/F13114928/bandit_anim.blend)

blender-admin commented

2022-05-31 16:18:08 +02:00

This issue was referenced by a5dcae0c64

This issue was referenced by a5dcae0c641604c033f852e41841f58460c40069

Kévin Dietrich commented

2022-05-31 16:18:38 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Kévin Dietrich closed this issue