For users it defines how accurate vertex positions are in terms
of limit surface (as in, how close the vertices locations to the
condition when they are calculated for an infinitely subdivided
mesh).
This affects things like:
- Irregular vertices (joint of 3 or more edges)
- Crease
Keep quality value low for performance.
NOTE: Going higher does not necessarily mean real improvement
in quality, ideal case might be reached well before maximum
quality of 10. Quality of 3 is a good starting point.
Internally quality is translated directly to adaptive subdivision
level.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3599
There are following reasons to do so:
- The plan is to replace it with some sort of object or viewport option,
so we can apply OpenSubdiv subdivisions on top of modifier stack and
keep modifier stack purely CPU side.
This will solve issues when adding some relation in scene will force
modifier to be evaluated on CPU.
- With new upcoming OpenSubdiv based CPU modifier implementation we can
cache topology similar to what GPU side was doing, which will already
be reasonably faster.
- OpenSubdiv GPU does not work since the OpenGL version bump, and is
to be rewritten with all the adaptive refine options kept in mind.
Since OpenSubdiv GPU was already broken and was only causing object
to become invisible, there is no reason to keep having that option in
the modifier.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3598
This replaces old single toggle option to subdivide UVs with
an enum which can have more options. The usecase for this is
to be compatible with other software. But we also might choose
different subdivision type as default in the future.
DNA and underlying code supports all possible options, but
only the ones which are compatible with old subdivision code
are currently exposes.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3575
The idea is to create vertices along the coarse edges once, without
splitting coarse edges on separate ptex faces. This requires some
indexing magic, vertices within a patch are no longer sequential.
Not sure how to make it nicer without such a black magic looking
calculations (which are basically boiling down to mimicking order
of verts/edges creation).
In the current offsets calculation loose verts and edges are not
properly taken into account, but those are causing topology refiner
to fail anyway, so it needs a bit deeper change.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D3570
The approach of setting 'refresh' flags on the modifier, and performing
the associated actions when the modifier is being evaluated, is a bad
one. Instead, we use the separation of the original and the evaluated
copy to 'refresh' certain things (because they simply aren't set at all
on the original). Other actions are now done directly with BKE_ocean_xxx
functions on the original data, intead of during evaluation.
The flag was only used in readfile.c, and resulted in a delayed call to
BKE_ocean_add(); this call is now immediately made instead as it's not
very expensive.
