Age | Commit message (Collapse) | Author |
|
Matches type better, avoiding possible confusion.
|
|
This is the only thing which needs to be done to perform propoer
reshape. Makes it easier to re-use code from other places.
|
|
There is nothing we need from object in this case.
|
|
|
|
Added propagation of displacement to a higher levels.
Has the same limitation as reshape from object, which makes
grids somewhat choppy due to linear interpolation nature.
This is to be addressed next.
|
|
The main goal of this patch is to cleanup the interface of every modifier. More specifically the interface of modifiers should be DerivedMesh-free.
Internally some modifiers still use DerivedMesh. However I think it is better when the wrappers are in the modifiers so that higher level functions can use the simplified interface.
This patch removes the applyModifier_DM and applyModifierEM_DM functions. In a previous patch (rB3614d9d) the other functions that used DerivedMesh have been removed.
Reviewers: brecht
|
|
|
|
Will speed up (or rather bring speed back to what it is supposed to be)
for brushes like smooth.
|
|
Currently is only working on an "inner" grid boundaries.
Need to implement averaging across face edges.
|
|
Allows to go to sculpt mode, do brush strokes, get out of sculpt mode
and have deformation preserved.
The issues currently is that the current implementation of CCG
storage is created from the limit surface, without displacement
taken into account. It is trivial to get displaced coordinates,
but it is more tricky to get displaced normals. This is something
to be solved next.
Another limitation is that this only works for sculpting at a maximal
multires level. There is code to be done to support propagation
of displacement onto a higher levels.
|
|
|
|
The issue there was that number of layers did not include normals,
while element size counts bytes used by normals. This sounds very
fragile and dangerous to work further. Also, one value can easily
be delivered from another, so it is redundancy going on here.
Possible difference now is that multires subdivision will copy
normals to a higher levels. Shouldn't be big of a problem, since
leaving old normals and updating coordinates is not correct either.
|
|
The one which is used by applying deformation modifiers on the multires.
|
|
Should use evaluated object to query deformed mesh from.
|
|
It is rather fully annoying to have same sets of obscure flags all over.
|
|
|
|
|
|
Currently behaves same as subsurf, support of displacement is the
next task in the line to tackle!
|
|
Currently no functional changes, just exposes all settings which we need
for OpenSubdiv, similar to what Subsurf modifier is doing already.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3602
|
|
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
|
|
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
|
|
|
|
We did not tell proper render/viewport context to subsurf derived mesh
created for multires.
|
|
|
|
|
|
It uses derived mesh, and relies on scene stored in modifier data.
So port is needed anyway.
|
|
|
|
|
|
The function definitions still reside in DerivedMesh.c. Once we're done
porting all the DerivedMesh use to Mesh, we'll move the still-relevant
functions to mesh_runtime.c. This move is now cumbersome due to shared
statically-declared utility functions in DerivedMesh.c
|
|
The contents of the ModifierEvalContext struct are constant while iterating
over the modifier stack. The struct thus should be only created once, outside
any loop over the modifiers.
|
|
Makes the follow changes:
- Add new `deform*` and `apply*` function pointers to `ModifierTypeInfo` that take `Mesh`, and rename the old functions to indicate that they take `DerivedMesh`. These new functions are currently set to `NULL` for all modifiers.
- Add wrapper `modifier_deform*` and `modifier_apply*` functions in two variants: one that works with `Mesh` and the other which works with `DerivedMesh` that is named with `*_DM_depercated`. These functions check which type of data the modifier supports and converts if necessary
- Update the rest of Blender to be aware and make use of these new functions
The goal of these changes is to make it possible to port to using `Mesh` incrementally without ever needing to enter into a state where modifiers don't work. After everything has been ported over the old functions and wrappers could be removed.
Reviewers: campbellbarton, sergey, mont29
Subscribers: sybren
Tags: #bf_blender_2.8
Differential Revision: https://developer.blender.org/D3155
|
|
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
|
|
This caused too many problems syncing object modes
with multiple objects/windows/workspaces, see: D3130 for details.
|
|
- Read-only access can often use EvaluationContext.object_mode
- Write access to go to WorkSpace.object_mode.
- Some TODO's remain (marked as "TODO/OBMODE")
- Add-ons will need updating
(context.active_object.mode -> context.workspace.object_mode)
- There will be small/medium issues that still need resolving
this does work on a basic level though.
See D3037
|
|
|
|
Solves these security issues from T52924:
CVE-2017-12081
CVE-2017-12082
CVE-2017-12086
CVE-2017-12099
CVE-2017-12100
CVE-2017-12101
CVE-2017-12105
While the specific overflow issue may be fixed, loading the repro .blend
files may still crash because they are incomplete and corrupt. The way
they crash may be impossible to exploit, but this is difficult to prove.
Differential Revision: https://developer.blender.org/D3002
|
|
Conflicts:
source/blender/blenkernel/intern/multires.c
|
|
|
|
Gives same kind of speedup too, 8.7ms with old OMP code, 2.7ms with new
one, with same level-4 multires monkey head.
|
|
New code is over three times quicker than old one here (e.g. Suzanne
subdiv level 4, 250k tris, threaded part is now 1.4ms instead of 4.5ms
with OMP).
|
|
Remove the critical OMP sections used to protect mem allocation.
First one can be done in a separate loop before main, parallelized one.
Second one only affect 'private' data, so we only need to ensure
guardedalloc thread safety is enabled.
This is committed as separated step to ease troubleshooting in case
bisecting becomes necesary.
|
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
|
|
GPU_buffer no longer has a fallback to client vertex arrays, so remove
comments about it.
Changed a few internal structs/function interfaces to use bool where
appropriate.
Use for-loop scope and flexible declaration placement. PBVH does the
same thing but needs ~150 fewer lines to do it!
The change to BLI_ghashIterator_init is admittedly hackish but makes
GHASH_ITER_INDEX nicer to use.
|
|
|
|
|
|
Notes:
* Code in rendering and in game engine will still convert
tangents to a tessface representation. Added code that
takes care of tangent layer only, might be removed
when BGE and rendering goes full mlooptri mode.
* Baking should work discovered some dead code while
I was working on the patch, also tangents are broken
when baking from multires (also in master), but those
are separate issues that can be fixed later.
This should fix T45491 as well
|
|
modifier.
Since it was not ensuring dest has valid mdisp data matching new multires modifier subdiv level...
Also, fixed a bug in `multires_subdivide()`, which would crash when trying to
increase from level 0 (aka no subdiv) to > 1 (wrong check, trying to interpolate
when it should not). And added a few sanity checks.
|