Search for subdivision_work
Latest is from September 20, 09:52:21
2 Likes
Hello Kevin, the performance on this branch is amazing! incredible work you have done, this is mind blowing and a total game changer, very promising, thank you for your tremendous work and that this can see light soon on Blender.
But if I may ask, I had a little doubt or question, sorry to have no knowledge, but does this and the Multires modifier not carry some similarity? I’ll get straight to the point, I tested with the Multires modifier thinking it would work, but it did not, are there plans for this optimization to be used with the Multires modifier or any possibility?
It would be interesting to see the possibility of animating sculpted characters with many details, in different sublevels giving the utility to MultiRes, and be able to have this incredible performance as in your implementation.
No those 2 are different things, though they might seem similar on the surface level.
1 Like
Reason that this speedup works is that for subdivision surface, positions of subdivided vertices depend only on coarse mesh, so this calculation can be offloaded to the GPU (I’m simplifying a bit). For multires, on top of subdivision you have displacement data, and CPU needs quick access to this data for sculpting to work, so there is no point in moving any of this to GPU.
3 Likes
It should work:
Model with Multires → bake multires to displacement → same model but with subdiv with gpu displacement.
Unfortunetly we dont have WPO in EEVEE/Workbench.
Anyway it would be cool if we had CPU Modifier stack and separate GPU modifier stack that comes after CPU. With operations like this OpenSubdiv, Displacement and some others that could be possibly ported to GPU.
I’m testing the latest build/think it is, on Windows 10 x64.
Was noticing Edit mode toggling really fast at first, with subD Mod last in the stack.
I then made some changes to edge sharps, and noticed a slightly decrease in speed toggling.
But then I tried to extrude 1 face outwards and was testing the toggle in and out of edit/object mode once again. But now it’s even slower yet… which is interesting…
It went from being basically instant at first, and then now its like 2-3.5~ seconds per toggle.
In 2.93 on the same mesh its actually faster… maybe 1-2 seconds.
Edit: Well I deleted all the stuff in the blender 3.0 scene, and copied/pasted it back from 2.93, and now it’s faster again. Even if I edit the mesh/toggle back and forth it, seems faster again… very strange.
Did you have snapping (or any other transform tool option) enabled? It could be that the need to have a CPU version of the data for such tools is causing the lags. Maybe this could still be improved.
2 Likes
For multires, it could be possible to use some of the GPU acceleration for some operations (like the “Reshape” operator).
There were some discussions about having an implementation for the GPU evaluator that is generic enough to be used elsewhere than for the last subdivision modifier. I am not sure if my work is generic enough, but, who knows, in the future it might be possible to use it in different context. Time will tell I guess.
7 Likes
@KWD With Opensubdiv officially delayed to 3.1 are you still actively working on it?
Going by what was shared in https://devtalk.blender.org/t/2021-09-28-blender-rendering-meeting/20664 It sounds like you are no longer actively working on it and have been reassigned to other tasks.
Brecht proposes Kévin works on Eevee generic attribute rendering for geometry nodes, since this is closely related to his work on Alembic generic attribute support and familiarity with this area due to the OpenSubdiv work. This might make it into 3.0 still.
Ah. Yeah. I think I had snapping on. Or I did at some point for sure.
Hi, sorry for the late response. I was busy in other areas, but I shall resume work on this shortly. Since I am working on generic attribute rendering for Eevee, this will need to be added to the OpenSubDiv patch.
12 Likes
I’m glad that you will keep working on and will return to it, be it shortly or a bit later (I can imagine the 3.0 release has priority now).
I look forward to seeing this in Master one day. You are steadily making it happen. 
4 Likes
Bcon1 for version 3.1 is a go.
rBdab3591588e9 (blender.org)
Is this patch going to go into master early in the new cycle or is some review needed yet? It is pretty important for just about any scene that uses subdivision surfaces.
2 Likes
Check his notes. He mentioned everything there.
Hope he gets the needed feedback.
4 Likes
i cant bellieve the subdiv patch its still has unknow future , its like a bad joke to be honest
2 Likes
Last time I check it’s waiting for another review so poking the reviewers in blender chat or in the patch should help more… but no spamming.
Usually, the really big Bcon1 patches don’t get committed until after the version before hits the release stage. That and the fact that Kevin still has to finish his work bringing attribute support to Eevee for version 3.0.
The beta period also tends to take a lot of developer time, it is not surprising that big ticket items have not seen a resumption of the review process.
8 Likes
Today I compared subD modeling to Modo… oh Modo like 50 times faster… damn!
User:KevinDietrich/Reports2021 - Blender Developer Wiki
I dropped the ball again and forgot to do a lot reports. Main work for the last month was the OpenSubDiv patch refactor.
- OpenSubDiv.
Refactor based on reviewers feedback is now complete. I am in the process of making sure is compiles properly as one change increased significantly the size of the patch. In order to ensure that a mesh is available on the CPU side as well, the modifier should be executed which requires a depsgraph. This changes a lot of areas of the code, and we should ensure that they only require a lazy subdivision evaluation if needed. I may have overdone it, but better be safe than sorry I guess. This is using the mesh wrapper API.
The patch is not in limbo, in fact it looks like there’s a pretty good chance of this going in soon.
13 Likes