| Age | Commit message (Collapse) | Author |
|---|
|
normals_split_custom_set()
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).
|
|
normals, instead of vertex normals.
User suggestion/request from 'boby'.
|
|
|
|
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
|
|
Also 'com' as abbreviation for center-of-mass is a bit confusing, rename to 'center'.
|
|
Patch D1417 by Martin Felke, with minor edits thanks!
|
|
|
|
|
|
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!
|
|
add a negated version of axis_dominant_v3_to_m3
|
|
|
|
|
|
|
|
edge vector stack was left un-cleared.
|
|
Also add depsgraph & physics
|
|
zero-normals.
Zero-normals here are used as a shortcut to say 'use auto-computed values'.
So we have to do so in pre-process steps!
|
|
loops.
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.
|
|
There is one case where we do can have only two edges for two loops...
|
|
|
|
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.
|
|
- area_quad_v3 now works correctly with concave quads.
- add area_squared_*** functions, to use when comparing to avoid a sqrt().
|
|
also add transform_point_by_seg_v3
|
|
|
|
|
|
Even if we cannot use computed lnor, we still have to empty the fan stack of lnors!
|
|
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.
|
|
|
|
- BLI_BITMAP_SET -> BLI_BITMAP_ENABLE
- BLI_BITMAP_CLEAR -> BLI_BITMAP_DISABLE
- BLI_BITMAP_GET -> BLI_BITMAP_TEST
- BLI_BITMAP_MODIFY -> BLI_BITMAP_SET
|
|
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 normal_poly_v3
|
|
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
|
|
|
|
|
|
|
|
|
|
cases
Own stupid typo in rB28ca299d4dfc...
|
|
Own bug from rBc691551249f3. Now at least I understand why `test_index_face()` is needed for tessellated quads!
Added a bunch of comments to explain the issue, as it's far from an obvious one...
We loose some performances, but it's still much quicker than org code.
|
|
|
|
to tessellate).
The main idea is to store (during tessellation) or recreate (during tessdata update) a tessfaceverts-to-loops mapping, and then update all tessdata
in one pass, instead of calling `BKE_mesh_loops_to_mface_corners` repeatedly for all tfaces!
Differential Revision: https://developer.blender.org/D226
Reviewed by Campbell, thanks a lot!
|
|
|
|
This simply mimics code used for loopnormals, to enable py scripts to generate and access (temporary)
a tangent 3D vector and bitangent sign for each loop. Together with the split normals, this allow
to recreate a complete tangent space for normal mapping (bitangent = bitangent_sign * cross(normal, tangent)).
Expects all faces to be tri or quads.
Reviewed By: Brecht, campbellbarton
Differential Revision: https://developer.blender.org/D185
|
