Subdivide n-gons

Archive User Feedback
1

This has already been written about, but I will write again to make it more fun.
There are two meshes:

2019-08-04-162601_1920x1080_scrot
2019-08-04-162601_1920x1080_scrot1920×1080 443 KB

The first is built of squares, and uses ~ 12,500 vertices, the second - one n-gon of 512 vertices.
In 2.7, the subdivision (Ctrl+2) of both occurs instantly.
In 2.8, the subdivision (even Ctrl+1) of the first mesh is a bit slower, and it completely kills the blender for the second mesh (512-gon).
Does anyone know the reason for this reaction to n-gons?
Or maybe I’m the only one who faces precisely this problem (subdivision of n-gons)?
Or maybe OpenSubdiv is not the best choice for a blender?

P.S.
The new blender pleases with great widgets and gizmos. All this is very beautiful and useful to use. You can forget about the keyboard, and work only with the mouse.

2

OpenSubdiv slows down a lot with n-gons in particular. It is a known issue. Not sure how easy it is to solve.

That has nothing to do with the speed of OpenSubdiv. Please stay on one topic at a time.

3

Can someone explain what the developers were guided by when introduce OpenSubdiv in a blender? (except that it is an industry standard!)
Now we need to wait when OpenSubdiv will work better? When do OpenSubdiv developers fix it?

4

OpenSubdiv, invented by Pixar, has much better creasing, and has the potential for much much faster evaluation and performance. esp when the calculations are performed on the GPU.

As for why it is generally slow in 2.8 currently, it is partly because it only runs on the CPU currently, but even so it seems counter-intuitively slow even then.

@sergey should know more.

5

I understand that the Kathmullah-Clark subdivision has many shortcomings. But it is excluded from the 2.8 blender without an adequate alternative.

6

The developers were guided by the following aspects of OpenSubdiv:

  • Better edge creases, especially on edges which are adjacent to a non-regular and non-manifold vertices.
  • Vertex crease support.
  • Topology cache, which allows to speedup CPU side evaluation.
  • GPU side subdivision.
  • Feature and camera adaptive subdivisions

Main slowdown is coming from a single-threaded nature of topology analyzer, which can be threaded now with sparse patches support on the OpenSubdiv side.
The N-Gons and non-regular vertices are indeed currently slower, but because of support of vertex crease and better edge crease in such cases (which was mentioned above).

2 Likes
7

Can we expect that in the future the OpenSubdiv performance for the blender will surpass the old method (when using the same processor, without using the GPU, under equal conditions)?

8

That’s the goal, yes.

In fact, it was already faster on Spring character at a time topology cache has been enabled.
Other cases will be worked on for 2.81 and 2.82.

2 Likes
9

In this case, all claims are withdrawn. Obviously it’s worth it for now.

Thank you for the answers.