| Age | Commit message (Collapse) | Author |
|---|
|
matching convention for fixed length api, eg: copy_v3_fl
|
|
Tessellation data isn't used for drawing or sculpting.
This frees up some memory ~approx 10% in own tests.
Also slight spee-up since it avoids calculating it in the first place.
|
|
|
|
|
|
|
|
The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the
mesh.
This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion
anyway.
Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1127
|
|
|
|
This is mandatory for incoming custom normal imports from io scripts, because
often geometry here is corrupted, so we need to call mesh.validate() to clean it up.
Issue is, we cannot set custom normals before geometry is clean, so we need to store
temporary plain loop normals in a CD_NORMAL layer, validate, and then set custom normals.
So we need a way to prevent 'temp' lnors to be freed by validate.
|
|
Code in ccgdm_draw_attrib_vertex() was entirely the same as the top
portion of the code in cddm_draw_attrib_vertex(). Moved this code to a
new function, DM_draw_attrib_vertex().
ccgdm_draw_attrib_vertex() was removed in favor of calling
DM_draw_attrib_vertex(). cddm_draw_attrib_vertex() still does a couple
extra things, so it still exists but calls DM_draw_attrib_vertex().
In the interest of easy code review, no changes made to the code in
DM_draw_attrib_vertex() other than the new name and an added comment.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1010
|
|
Issue was, when requesting (building) lnors for a mesh that has
autosmooth disabled, one would expect to simply get vnors as lnors.
Until now, it wasn't the case, which was bad e.g. for normal projections
of loops in recent remap code (projecting along split loop normals
when you would expect projection along vertex normals...).
Also, removed the 'angle' parameter from RNA's `mesh.calc_normals_split`.
This should *always* use mesh settings (both autosmooth and smoothresh),
otherwise once again we'd get inconsistencies in some cases.
Will update fbx and obj addons too.
|
|
|
|
Not much to add, modifier uses same code as operator basically, only key difference
is that modifier will never create data layers itself, you have to use dedicated operator
for that.
|
|
|
|
Modifier stack should ignore sculpt restrictions when creating derived render.
|
|
Was own mistake in handling custom data layers in boolean modifier.
Campbell, do you mind double-checking if it's all correct?
|
|
|
|
|
|
BKE_object_deform.
Along with some minor cleanup and simplifications.
Reviewers: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D903
|
|
We are handling a keyblock here, not a whole key(set). Names are alreay a bit confusing,
let's be consistent at least.
|
|
|
|
layer index was being obtained for loop data types but we referenced
Tessface data types
NULLing those out since only the data offsets are used in edit mode and
address sanitizer complains about freed memory access.
Also minor comment in texpainting
|
|
https://developer.blender.org/D643
Separates graphics context creation from window code in Ghost so that they can vary separately.
|
|
It did not cause an actual bug, this code path is never executed at the moment.
|
|
|
|
The problem was it used copied verts on the opposite side.
|
|
|
|
Indeed, constructive modifiers are highly likely to modify CDLayers like vgroups or vcols!
See vertexgroup2.blend file ({F93770}) in T40523, especially obvious with subsurf modifier.
|
|
Note this func needs some love, but this will be for later (should never have been in shrinkwrap code!).
|
|
Add ability to select UV layer from the layer panel.
|
|
Yep, at last it's here!
There are a few minor issues remaining but development can go on in
master after discussion at blender institute.
For full list of features see:
http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting
Thanks to Sergey and Campbell for the extensive review and to the
countless artists that have given their input and reported issues during
development.
|
|
|
|
use for DM_to_mesh to avoid clobbering the ListBase
|
|
D608 by Gaia Clary
|
|
|
|
Show that modifier may not be supported in dyntopo rather than sculpt
mode in general. This is useful information since users may confuse the
two. Multires for instance is surely supported in sculpt mode, but not
in dyntopo.
|
|
Warn when a modifier does not support optimal drawing and mask/hidden
parts display.
User report was that hidden parts became visible after adding a new
modifier subdivision. Subdivision was added with the Ctrl+number keys.
First part of the fix was to make sure we add a multires instead of the
subsurf modifier in sculpt mode with the PageUp/Down Ctrl+number keys.
We can't really stop users from having added a subsurf modifier already.
We could be "smart" and convert subsurf to mulrires upon entering sculpt
mode maybe but that can easily backfire - or users may actually want
that. For now, just warn that the modifier won't support Hiding/Masking
and optimal drawing.
|
|
No need to call `dm_ensure_display_normals()` when using loop normals,
poly/vert ones have already been computed!
|
|
Prepend BKE_ to the functions moved in blenkernel for recent bug fix.
|
|
Sculpt mode drawing fails after deleting a subsurf modifier
in sculpt mode and undoing.
This was quite difficult to spot. Main cause was that mesh data was not
synchronized properly between undo and sculpt code because we generated
a pbvh on derivedmesh invalidation without really refreshing the rest of
the data. This could result in undo and drawing operating on different
data.
To solve this and avoid bad level calls I had to move quite some code
around. Crazyspace is now moved to blenkernel, as did some sculpt calls
that make sure sculpt data are properly refreshed.
|
|
The issue was caused by the temporary CD layers being allocated for subsurf
meshes, same as we've got back in 881fb43.
In the long run this temporary storage is to be re-considered, but it'll also
imply re-considering of the Derivedmesh interaction as well. For now let's
use a simpler solution which is forbidding modifiers to call getArray for other
objects' derivedMeshes but use an API calls which would allocate local copy of
the data preventing race condition of shared data in DM.
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
handling code between
editmode and objectmode functions. No behavioral change expected!
|
|
subsurf one).
Just always tag tessellated CDlayers as dirty when we recompute split normals!
Also simplified a bit end of mesh_calc_modifiers.
|
|
|
|
here):
* Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf).
EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit.
* Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it
(tessellation, rna access, etc.).
* Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable
split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding
this option is now incoherent, will be addressed in a separate commit.
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D365
|
|
|
|
|
|
The variables are considered invalid unless DM_update_materials is
called prior to use. Only use case currently is
mesh drawing. This helps with excessive allocation on the stack during
GPUObject creation, but may help elsewhere in the future as well.
|
