Viewport modernization/optimization; It has begun

These two recent commits by Psy-Fi should explain it all

A major improvement to the drawing speed of subsurfed meshes
http://lists.blender.org/pipermail/bf-blender-cvs/2015-June/078636.html

A 20 to 25 percent speedup in general solid mode drawing.
http://lists.blender.org/pipermail/bf-blender-cvs/2015-June/078637.html

Both of them in a temporary branch as of now, but it goes to show that the viewport optimization is now an actual, ongoing project and should allay fears that the long-term plans for the Gooseberry project rendered it into a mere pipedream. The BF has known that this was needed and they are starting to get it done.

No fancy new graphical capabilities yet, but I do think that this is more important as of now.

So yes, it has begun :slight_smile:

The corresponding code.blender.org article (very technical)
http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh-drawing-part-1/

Some interesting stuff here if you understand it, apparently the 2.75 release will already have some optimizations to wireframe drawing.

Any speed improvement on sculpting dense meshes (Dyntopo)?

Will it helps with current vertex paint mode slowness on sculpt/high poly ?

No to both questions. Sculpting draw code is quite optimal already and vertex paint slowness comes from the painting algorithm, not mesh drawing.

Great, this is a very good news.

Very strange the upgrade don’t help the sculpt process, one of the reason I using zbrush is the more powerful viewport and capability to handle tons of poly make possible sculpt very subtle details.

Very strange the upgrade don’t help the sculpt process, one of the reason I using zbrush is the more powerful viewport and capability to handle tons of poly make possible sculpt very subtle details.

Well as Psy-Fi said, the reason Blender is slow here is less because of the drawing code. There are much more possible performance bottlenecks than just the viewport drawing

So the sculpt will not be smoother any time ?

Zbrush uses the CPU, Blender the GPU, Blender should be faster and smoother no ?

Thanks for the precision Psy-Fi

No, this is a very simplified way to view things. Another similar myth is: If you throw more cores at it it will go faster. The speed depends on the slowest component, or bottleneck, which is mostly on the CPU for blender. Obviously zBrush coders are really good since they’ve managed to squeeze so much performance out of the CPU only. We do use some tricks as well but blender is not a specialized sculpt software and keeping the sculpt part consistent with the rest of the program has its own set of costs and limitations.

Blender sculpting is really 3 systems: Mesh, Multires and Dyntopo sculpting, each with its own performance characteristics.
I assume when we speak about zBrush vs Blender we speak about multires sculpting. While multires is indeed slower and buggy, we haven’t spent too much time optimizing that part of blender really.

To recap: viewport is not really about tool (sculpting/painting) or animation performance, it’s about screen refresh performance (panning, number of triangles on screen) and appearance (shaders). Currently I am mostly focusing on really problematic display code of blender, such as subsurf and probably edit mode as well. All in preparation for the shader based viewport we will be making.

Edit: question answered before I even asked :stuck_out_tongue:

Ok Thank you for your answer Psy-fi, it’s clear now ^^

Hi Psy-Fi,

With this commit,
http://lists.blender.org/pipermail/bf-blender-cvs/2015-June/078636.html
if using a Subsurf modifier at the end of a modifier stack, does it mean a ‘dummy’ SimpleDeform modifier (with zero settings) is no longer required to be placed after the Subsurf modifier to maintain performance?

Thank you for your continuing impressive Blender developments!

David

Correct, subsurf should be as fast as any other mesh drawing.

I just want to make something clear, ZBrush is not fast nor faster than Blender (multi-res) viewport drawing.

Up until recently ZB was a 32 bit program. That means it could only use around 4GB of memory. Therefore the maximum number of vertices (points in ZB) was around 25 M vertices (you needed to set this from the preferences the default was 16M i think).

This means each subtool (individual sculpt object) could be maximum 25M vertices.

So technically you would have a sculpt file which had 100 subtools each with 25M vertices. With a 2.5 Billion vertices (technically :))

Even if you subdivided a single model until 25M and sculpted it viewport would become unresponsive or laggy (and usually crash).
You would needed to clip the visible area to work smoothly. Most of the time you also needed to hide couple of subtools to reduce viewport lag when you had many subtools.

ZB knew about this problem so they implemented “Dynamic Solo” mode. (Basically solo mode is Blender’s “View Local” - Dynamic Solo hides all other sculpt objects when you move/pan/zoom the viewport).

ZB 's HD sculpting feature also has this limitation (the maximum are you can work smoothly in HD is automatically clipped to 9M vertices ).

Blender sculpting - multi-res can go around 64M - 96M verices for multi-res sculpting. You can pan zoom and rotate easily with “Fast Navigate” on and “Threaded Sculpting” bypasses any lag.

So ZB viewport drawing is not faster nor better than Blender. It is the opposite.

yep but in blender you cannot have X models with 25M polys in the viewport.
With the psy-fi commit it should be better.

Yes , Psy-Fi 's commit will help a lot for better performance. just note that ZB isn’t better.

Wow!
From many comments I’ve previously read about poor viewport performance in connection with subsurf modifiers, this will be one of the most eagerly anticipated improvements. :slight_smile:

Do you need beta testers?

A couple of steps to get textured mesh drawing sped up
http://lists.blender.org/pipermail/bf-blender-cvs/2015-June/078671.html
http://lists.blender.org/pipermail/bf-blender-cvs/2015-June/078673.html

David Black; I’m pretty sure that all of these optimizations will be in master not long after the official 2.75 release (as the fact we’re closing in on the release is the reason why they are not already in master).

The branch is test_display_optimizations for those who want to test it. The branch should be pretty safe to work with though I’ve had a few weird occasional crashes. They are not reproduced reliably so if more people can test it would help. Also would be interested to know if memory is a concern especially for heavy scenes, since display data for subsurfed meshes, which have a hefty vertex count are now cached. I guess if people use bogus modifiers after subsurf they are more interested in speed rather than memory, since bogus modifier has the same big memory footprint.