Only concerns poly normals computing, have usual 10% speedup of affected code for OMP -> BLI_task switching.
Also parallelized the 'weighted accum' part (used when computing both polys and vertices normals,
when using modifiers e.g.), which gives nice 325% speedup (from 66ms to 20ms for a 500k poly monkey
with simple deform modifier e.g.). ;)
Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and
loop normals of a given shapekey.
This will be used e.g. in FBX exporter (shapekeys need normal data too).
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1510
This was simply broken for vertex case (indexing loop normals with vert indices...).
Turns out to be rather verbose to replace on-the-fly zero normals by default ones correctly,
and do not want to make a full copy of the given custom normals array, so now this one is
editied in place (replacing zero vectors by correct default normals). Don't think this
could be a serious issue anyway.
The detection of needed sharp edges (based on given loop normals) would not fully work
on first run in case we started with a complete smooth cyclic loop fan (edge between
first and last loop of the fan would not get checked).
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
This stores loop indices into the loop array giving easier acess
to data such as vertex-colors and UV's,
removing the need to store an MFace duplicate of custom-data.
This doesn't yet move all internal code from MFace to LoopTri just yet.
Only applies to:
- opengl drawing
- sculpting (pbvh)
- vertex/weight paint
Thanks to @psy-fi for review, fixes and improvements to drawing!
Simply check and early return in case we have no source or destination items
(verts/edges/loops/polys) available...
Also, fix an assert in `BKE_mesh_calc_normals_poly()`, when called with no poly.
Error in custom split normals work, non-autosmooth normals != vertex normals!
Loops from flat faces shall take normal of their face, not their vertex.
Tsst...
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.
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.
This was a ToDo item, for mesh-based rigid body shapes (trimesh, convex)
the operator was simply using the bounding box volume, which can grossly
overestimate the volume and mass.
Calculating the actual volume of a mesh is not so difficult after all,
see e.g.
http://research.microsoft.com/en-us/um/people/chazhang/publications/icip01_ChaZhang.pdf
This patch also allows calculating the center-of-mass in the same way.
This is currently unused, because the rigid body system assumes the CoM
to be the same as the geometric object center. This is fine most of the
time, adding such user settings for "center-of-mass offset" would also
add quite a bit of complexity in user space, but it could be necessary
at some point. A number of other physical properties could be calculated
using the same principle, e.g. the moment of inertia.
Better fix than rBbef5cb3aa2e5a: consider edges between faces with opposed normals as sharp.
In fact, previous code was broken more deeply in this case (inconsistent normals across
a 'smooth fan') - some loop normals would even never be computed!
Fixing this is possible (even wrote it, actually), but this adds more complexity
to a piece of code that is already awfully complicated, *and* normals in that kind
of smooth fan do not make much sense anyway. So simpler and nicer results with
assuming sharp edges between such 'opposed' faces!
Note that there is some face (loop) ordering black magic at work here, added more comments
to try to explain how and why all this works.
As a bonus, we do not need to check for already computed loop normals anymore, since we
know each 'smooth fan' will be walked once, and only once.
This crash can only happen in case faces in same 'smooth fan' have reversed normals.
To support this, we have to always keep a way to get real values in loop_to_poly,
even when loop itself is tagged as done, it might be needed in computation of one of
its neighbor's split normal later.
Tessellated split normals CDlayer had no swap func, hence ugly little test_index_face()
could not rotate its values correctly when rotating tessellated faces...
Extra-reported in T39735.
* 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
