| Age | Commit message (Collapse) | Author |
|---|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
Part of D4277 by @sobakasu
|
|
|
|
There is no point having operations that iterate over the whole
bit array as macros, so convert BLI_BITMAP_SET_ALL to a function.
Also, add more utilities for copying and manipulating masks.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D4101
|
|
|
|
Differential Revision: https://developer.blender.org/D3719
|
|
Terms get/set don't make much sense when casting values.
Name macros so the conversion is obvious,
use common prefix for easier completion.
- GET_INT_FROM_POINTER -> POINTER_AS_INT
- SET_INT_IN_POINTER -> POINTER_FROM_INT
- GET_UINT_FROM_POINTER -> POINTER_AS_UINT
- SET_UINT_IN_POINTER -> POINTER_FROM_UINT
|
|
|
|
|
|
|
|
That area is now officially purged from the Devil.. errr... DerivedMesh!
|
|
This was actually rather hairy, this code is huge and complicated, easy
to make mistakes...
Good thing is, it will allow for significant simplification and more
(name) cleanup in following commits ;)
|
|
This member currently doubles the value of `ray->radius` or is not even used.
|
|
with `bvhtree_from_mesh_get`.
|
|
bvhtrees.
Use ray radius instead.
|
|
If you need the approximation, use raycast radius.
|
|
with epsilon equal to the value of ray_radius.
This is the desirable behavior.
It also removes one more use of `bvhtree_from_mesh_looptri`.
|
|
Interpolated` and `Ray Radius` other than 0.0.
`MREMAP_RAYCAST_APPROXIMATE_BVHEPSILON(ray_radius)` greatly increased the radius making for example that 0.1 becoming 1.5
Now the result is much more predictable.
|
|
This will allow greater control of the bvhtrees that are obtained, and helps identify problems.
It is also an additional step to unify the functions.
|
|
identifier type.
Reviewed By: @campbellbarton
Differential Revision: https://developer.blender.org/D3192
|
|
Some of these API's can have 3D versions, explicitly name them 2D.
|
|
faces.
Odd nobody noticed this earlier, was obvious bug in code logic here... :/
To be backported to 2.79a.
|
|
|
|
That one was doing exactly same thing as `dm->getLoopTriArray()`, no
point in having twice the same code here...
|
|
arrays again from DM.
This was... horribly wrong, CDDM will often *not* need to allocate
anything to return arrays of mesh items! Just check whether array
pointer is NULL.
Also, remove `DM_get_looptri_array`, that one is useless currently,
`dm->getLoopTriArray` will always return cached array (computing it if
needed).
|
|
|
|
Own very stupid mistake this time... :|
|
|
Pretty nice copy/paste typo in looptri work...
|
|
Also, cleanup, reduce declarations of tmp_co/_no...
|
|
shapekey.
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
|
|
|
|
Issue from rBabbd82a50, loops data were not correctly protected against multi-freeing in bvhtree data.
|
|
poly projection.
Null-area face could generate an int overflow, and potential numerical imprecision in face area computation
could lead to negative number of rays-to-cast (though highly unlikely).
Also, use domnant axis of poly normal as 'flattening' one, instead of always using Z axis.
Points raised by Campbell, thanks!
|
|
|
|
|
|
|
|
|
|
|
|
from their compilers as errors, even the stupidest ones!
|
|
matches best the source one.
This allows to match and transfer data between two meshes with similar shape but complete arbitrary different transform.
Note that the result will be best if the meshes (more precisely, their vertices) are exact copies of each other.
Otherwise, method used can only perform an approximated best match, which means you'll likely get better
results if you 'visually' make them match in 3D space (and use 'Object Transform') instead.
|
|
In org work, bvhtree helpers were modifying passed co/no in place according to given transform.
However, during review pass we decided this was bad, and made them modify copies. But this broke
some cases where we'd do extra tests after bvhtree query, expecting tmp_co to be in tree (aka source) space!
Further more, since in quite a few cases we were already doing that transform outside of bvhtree helpers,
decided to remove this alltogether from the helpers - makes things more clear and easy to follow,
avoids needless copy of vector, and ensures we are always using tmp_co in its transformed version!
|
|
Own stupid mistake in rBcdabf7e3...
|
|
matching convention for fixed length api, eg: copy_v3_fl
|
|
This commit fixes several issues:
* island_store->items_to_islands_num was reset each time we added a new island, this is stupid! Harmless too, though, afaikt.
* partial verts bvhtree (with several islands) was hugely over-allocated...
* we would 'leak' in neighbor islands when geometry itself was contiguous.
* best_nor_dot was used incorrectly, leading to smaller weights for better matching normal!
All those fixes are related to T44522 (through personal communications with reporter).
|
|
matching normal' modes
would fail on coplanar faces (or smooth verts).
Loop remapping is really a tricky topic... For now, we enhance a bit more
our Frankenfunc by using distance between dest and source polygons as
fallback in case we have too much similar normals...
Probably not a perfect solution, but should be robust enough I hope.
One core question remains open though: do we want to stick to 'use only seams
to detect UV islands'? This makes things much simpler, but will obviously fail
in case of actual islands without matching seams. :/
|
|
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.
|
