Age | Commit message (Collapse) | Author |
|
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
|
|
By argument naming and convention this is the intended argument order.
|
|
|
|
|
|
|
|
The default one is now UVs are smoothed, boundaries are kept sharp.
After some time of experimentation seems this is better default from
interoperability point of view.
This fixes distortion reported in T83470.
Differential Revision: https://developer.blender.org/D10111
|
|
The simple subdivision as a type only causes issues like no-continuous
normals across edges, inability to reliably switch the type and things
like this.
The new subdivision operators supports wider variety of how to add
details to the model, which are more powerful than a single one-time
decision on the subdivision type.
The versioning code is adjusting topology converter to specify all
edges as infinitely sharp. The reason for this (instead of using
settings.is_simple) is because in a longer term the simple subdivision
will be removed from Subsurf modifier as well, and will be replaced
with more efficient bmesh-based modifier.
This is finished up version of D8436.
Differential Revision: https://developer.blender.org/D9350
|
|
Is no longer used, fully replaced with more powerful algorithm.
|
|
|
|
It was rather a huge chunk of code, which started to become
more harder to maintain with the transition to OpenSubdiv based
implementation. Because of this transition, the compatibility was
also rather on a poor side.
Remove compatibility support for pre-2.50.9 multires.
Ref T77107
Reviewed By: brecht, mont29
Differential Revision: https://developer.blender.org/D9238
|
|
Also order sizeof(..) first to promote other values to size_t.
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenkernel` module.
No functional changes.
|
|
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
|
|
|
|
|
|
This introduces two alternative subdivision modes that generates
displacement on the grids that look as Simple subdivisions but while
using the Catmull-Clark subdivision type in the modifier. This way,
Simple and Catmull-Clark subdivision can be combined when creating new
levels if needed, for example, to sculpt hard surface objects.
Subdivide simple smooths the sculpted data when creating a new
subdivision level. Subdivide linear also preserves the sharpness
in the sculpted data.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7415
|
|
Return the correct sculpt level in BKE_multires_sculpt_level_get and
enable the property in the UI
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7575
|
|
There is no user visible difference in standard builds, as there are no
volume modifiers yet. When using WITH_NEW_OBJECT_TYPES some deform only
modifiers are now available for hair and pointcloud objects.
Differential Revision: https://developer.blender.org/D7141
|
|
Allows to know what level sculpting has been done after the value has
been changed in the MultiresModifierData.
No functional changes, just preparing code to have everything needed
for propagation undo.
Differential Revision: https://developer.blender.org/D7307
|
|
Might have happened when Apply Base is used in sculpt mode.
In practice this probably was fine, since the operator tags object
for update, so the pointers will be restored back to what they should
be.
|
|
It is not guaranteed that with Multires modifier existing there
will be CD_MDISPS and CD_GRID_PAINT_MASK custom data layers.
Fixes assert in the following scenario:
- With default cube, go to edit mode
- Add Multires modifier
- Remove the Multires modifier
|
|
|
|
The initial code from earlier from today didn't really work reliable
since it is not possible to apply virtual modifiers but not the real
multires one (in a situation like mesh with shapekeys and multires).
New code uses less memory and has better performance for the case
when there are actual modifiers leading the multires. The case when
there is only multires will not be as performant as possible at this
moment.
|
|
The new function will use original object as a starting point
and apply all enabled deformation modifiers prior to the multires.
|
|
Use full argument name.
Also order arguments in the generosity order: from depsgraph
(which has everything) to object (which contains multires)
specific multires modifier.
|
|
Scene can be queried from the dependency graph.
|
|
Was happening when object does not have CD_MDISPS allocated yet.
Need to make sure totdisp and level is specified on CD_MDISPS data
prior to loading (as the load expects them to be properly set).
|
|
This change fixes artifacts produced by these operations.
On a technical aspect this is done by porting all of the operations
to the new subdivision surface implementation which ensures that
tangent space used to evaluate modifier and those operations is
exactly the same (before modifier will use new code and the operations
will still use an old one).
The next step is to get sculpting on a non-top level to work, and
that actually requires fixes in the undo system.
|
|
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
|
|
Was happening when leaving sculpt mode, introducing unnecessary lag
to the operation.
|
|
|
|
|
|
ss->multires is set in sculpt_update_object, which is not called just
after disabling dyntopo, so it needs to be checked before running
reshapeFromCCG
Reviewed By: campbellbarton, brecht
Maniphest Tasks: T73706
Differential Revision: https://developer.blender.org/D6801
|
|
|
|
This is a workaround for T58473 to avoid likely event of ruining
sculpted data.
Differential Revision: https://developer.blender.org/D6244
|
|
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5831
|
|
Make a distinction between flush sculpt changes for rendering, and forcing
sculpt data structures to be rebuilt after mesh changes. Also don't use PBVH
for renders.
|
|
|
|
When the result isn't used, prefer post increment/decrement
(already used nearly everywhere in Blender).
|
|
TLS and Settings can be used by other types of parallel 'for loops', so
removing 'Range' from their names.
No functional changes expected here.
|
|
|
|
|
|
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
|