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 the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
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.
Basically, our drawing code assumed we always use the edit mesh
materials, which can be different from the derived mesh
materials in modifiers doing overrides. We usually we want to use the
derived mesh when it is available instead.
There are two fixes here for both solid and textured mode. Unfortunately
the fixes do not help to make the display code less labyrinthian but I
expect this "should work" (tm and famous last words)
Solid mode fix is 95% from Bastien, thanks!
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.
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.
So, turned out after all we need a foreachmapped helper for loops as well... :/
CDDM and EBDM were reasonably simple, but I fought hours with CCGDM (subsurf) to find only a
bad working solution (see D478). So I fallback to a code similar to CDDM one.
Probably not nice for performances, but loops and subsurf are not matching well...
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D478
* 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.
Instead of having ifdef __GNUC__ all over the headers
to use special compiler's hints use a special file where
all things like this are concentrated.
Makes code easier to follow and allows to manage special
attributes in more efficient way.
Thanks Campbell for review!
this means in editmode with wire draw, face and vertex normals don't have to be calculated at all.
in most cases the normals are not used so add a flag that makes calculating them only for functions that need them.
also fix face normal calculation for CDDM, was using quad calculation for ngons too.
add arguments to calculate normals when converting to bmesh:
BM_mesh_bm_from_me, DM_to_bmesh
This gives some speedup to undo (which didnt need to re-calculate vertex normals), and array modifier which doesnt need to calculate face normals at all
many modifiers were calculating normals, when those normals were ignored by the next modifier.
now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback.
Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
- pass string size to BLI_timestr() to avoid possible buffer overrun.
- quiet warning for mingw.
- include guards for windows utf conversion funcs.
- fix for mistage in edge-angle-selection check.
- some style cleanup.
reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer
for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces.
(CD_POLYINDEX and CD_ORIGINDEX).
as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on
the same derived mesh, and polygons only store the original index values.
Appart from the color glitch, there was several problems with vpaint:
* "fast_update" mode was never on, because of wrong testing code;
* drawing refresh during stroke in "fast_update" (i.e. no dm rebuild) mode was broken in VBO mode, because updated (tess data) mcol wasn't moved to colors GPUBuffer.
Solved the later point by adding a new DM_DIRTY_MCOL_UPDATE_DRAW flag to DerivedMesh dirty var, which is set each time vpaint stroke directly update me->mcol, and forces GPU_color_setup() to refresh the gpu's colors buffer.
Also got rid of the uggly GPU_color3_upload(), which basically did the same thing, but with an additional intermediate buffer !
* Changes to DerivedMesh interface: DMGridData has been removed,
getGridData() now returns an array of CCGElem pointers. Also added
getGridKey() to initialize a CCGKey (implemented only by
CCGDerivedMesh.)
* PBVH: added BLI_pbvh_get_grid_key().
* A lot of code is affected, but mainly is just replacing
DMGridData.co, DMGridData.no, and sizeof(DMGridData) with the
CCG_*_elem functions, removing the reliance on grid elements of
exactly six floats.
Any identifier that looks like an OpenGL identifier, but isn't, causes a false alarm by the glreport.py tool. Most of these were in comments so I just rephrased the comments. There were a couple of static functions/macros that were easy enough to rename. Only the glTexco and glIndex fields of the DMVertexAttribs struct was public and had non-local uses.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
