In T97877#1353605, @Clément Foucault (fclem) wrote:

@Kévin Dietrich (kevindietrich) This might happen because of multiple reasons:

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

I can't seem to be able to reproduce (Linux/NVidia), I doubt it is a driver thing, probably depending on the system, some updates are merged or missing/not caught? At least to me it is instant, either by using the shortcut (e.g. ctrl+1) or by adding the modifier manually, the stats immediately update.

Move render mutex to CurvesBatchCache.

Address review comments.

• Fix compile error/rebase.

• Fix compile error/rebase with master.

Add CurvesInfos which holds an array of booleans to determine the scope
of an attribute. This array is indexed based on the attribute loading order.
Since some attributes may not be used in the material (e.g. disconnected
attribute node), we cannot use the same indexing as DRW_Attributes, so a
mapping to the index inside of the material attribute list is done.

Address review comments.

I am not too sure about using std::mutex (unless it is unanimously requested). The reason being that I don't like that synchronization primitives being used all over the place, even if it is simple. This is less error prone to encapsulate the locking/unlocking inside of drw_attributes_merge.

• Update VBO name (following changes in master).
• Remove static attribute, use ".selection_point_bool" as suggested.

In D11591#402054, @Rowan Ibbeken (Rowquino) wrote:

I was wondering what the progress was on this? Will this make it into 3.3?

I made P2955 (applies on top of this patch) to use the extra source data introduced here in the draw code for the orco layer, as currently it is doing linear interpolation, like any other custom data layer.

Just to note, I was about to send a simple patch to fix the bug by recreating the layer when creating the wrapper, as indeed there is no interpolation for CD_ORCO. I guess this approach is a bit more robust, and also handles CD_CLOTH_ORCO I see.

• Rebase with master/D11591.

• Rebase with master.

BKE_subsurf_modifier_can_do_gpu_subdiv_ex could be renamed to lose the _ex suffix, and its skip_check_is_last parameter can be removed since it is only used in the modifier code now (but checking if it's the last modifier still needs to happen).

Closing manually as I somehow used the wrong task number when committing the fix, should be fixed by rBfa9e878e7935.

• Unnecessary change

• Fix missing update when tweaking shaders.

• Add support for point domains.
• Deduplicate code with mesh attributes handling
• Fix memory leak.

@Clément Foucault (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.

Lowering the priority on this one as no one in the module team seem to have the right hardware to reproduce and fix this.

As far as I can tell, this is the same as T97086: something is wrong multiple objects are in UV edit mode. Since the other report is older, will merge this one into it.

@Manuel (krieghof) this might be the same as T96836: UV verts dont draw if certain modifiers are present (e.g geometry nodes, GPU subdiv, WeightedNormal w/o Autosmooth), maybe try with an empty geometry node modifier like in the other report. If it works then you might want to open create a new bug report for it.

(Also replying to your comment in the chat.)

As far as I can tell this is the same issue as T97650. Shadow rays intersect lots of faces from the volume mesh, which may exceed the max transparency bounces. As a workaround you can try to increase the maximum number of transparency bounce in Render Properties > Light Path > Max Bounces. (In your file 18 bounces seem to do the trick.)

Apparently same issue as T95527 as rB5d7ee4440650 fixes this as well.

This is the same as T96596. You can try a newer build which has a fix for EEVEE at least.

Indeed this is not yet supported. We track adaptive subdivision tasks in T53901: Cycles adaptive subdivision tasks instead of bug reports, since this is not a supported feature yet. I will add it there and archive this. I'll see to it that the manual is updated.

Apply changes from Hans' patch. I don't see any issues with them
and everything seems to work fine.

I commited the fix in the release without changes to`eevee_next` as attr_load_uv and attr_load_color are also used for the grease pencil which uses a couple of global variables (g_uvs and g_color). These globals are set via another shader, so I am not really sure what should be done here. I haven't looked deeply at the surrounding code, so maybe there is an easy solution I have missed.

Closing this as the issue was not about order of modifiers, but order in which data is requested by the draw code.

The new version of OpenSubDiv has some changes for OpenGL initialization problems on MacOS. Maybe this causes some issues on AMD cards. Or maybe it is something else.

In D13730#398509, @Clément Foucault (fclem) wrote:

You might have to remove the attr_load_color and attr_load_uv from eevee_next too now. You can do that during commit.

Rebase on master.