| Age | Commit message (Collapse) | Author |
|---|
|
Was own mistake in handling custom data layers in boolean modifier.
Campbell, do you mind double-checking if it's all correct?
|
|
|
|
|
|
|
|
|
|
Own regression since e08db08. CustomData_copy_data() would fail in cases
when mvert/medge/mloop/mpoly arrays were lazy allocated since that change.
Now made it so this layers are copying from own copy of the arrays.
Not sure if this still misses some CD to be copied, from quick glance
seems no, but some further testing wouldn't hurt at all.
|
|
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).
|
|
|
|
|
|
|
|
Goal of this commit is to support NGons for boolean modifier
(currently mesh is being tessellated before performing boolean
operation) and also solve the limitation of loosing edge custom
data layers after boolean operation is performed.
Main idea is to make it so boolean modifier uses Carve library
directly via it's C-API, avoiding BSP intermediate level which
was doubling amount of memory needed for the operation and which
also used quite reasonable amount of overhead time.
Perhaps memory usage and CPU usage are the same after all the
features are implemented but we've got support now:
- ORIGINDEX for all the geometry
- Interpolation of edge custom data (seams, crease)
- NGons support
Triangulation rule is changed now as well, so now non-flat
polygons are not being merged back after Carve work. This is
so because it's not so trivial to support for NGons and
having different behavior for quads and NGons is even more
creepy.
Reviewers: lukastoenne, campbellbarton
Differential Revision: https://developer.blender.org/D274
|
|
|
|
|
|
but its not needed.
Now add asserts to make sure this layer is only added once the modifier stack has been calculated.
this saves normal layer being calculated whenver vertex normals need updating.
|
|
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.
|
|
- mult_m4_m4m4 -> mul_m4_m4m4
- mult_m3_m3m4 -> mul_m3_m3m4
these temporary names were used to avoid problems when argument order was switched.
|
|
meshes.
|
|
where possible.
also found unintentionally defined enum/struct variables that where only meant to be defining the type.
|
|
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
|
|
|
|
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.
|
|
assigned: object, obdata, by userpref(default) (as discussed with ideasman_42)
|
|
|
|
|
|
Added four new functions as shortcuts to creating GHashes that use the
standard ptr/str/int/pair hash and compare functions.
GHash *BLI_ghash_ptr_new(const char *info);
GHash *BLI_ghash_str_new(const char *info);
GHash *BLI_ghash_int_new(const char *info);
GHash *BLI_ghash_pair_new(const char *info);
Replaced almost all occurrences of BLI_ghash_new() with one of the
above functions.
|
|
|
|
also use ..._find_name(..., name) rather then ..._find_named(..., name) --- both were used.
|
|
|
|
|
|
|
|
|
|
else if's
|
|
CDDM_tessfaces_to_faces wasbt updating the polyindex (missed incrementing the polyindex pointer).
also added an assert so non release builds will complain when CDDM_calc_edges_tessface() needs to run before CDDM_tessfaces_to_faces().
|
|
the problem remains (though not quite as bad) but think this is because of a bug elsewhere.
|
|
|
|
|
|
|
|
Seems that after converting tessfaces into faces normals should be re-calculated.
At least that's what happening in some other modifiers and what makes boolean
work fine with smooth normals.
|
|
|
|
Issue was caused by resetting face's mat_nr to zero if there's no material
map sent to ConvertCSGDescriptorsToDerivedMesh. In case of boolean modifier
we can't use such map because we can't affect on materials present in object.
So the only way which can give reasonable result is:
- Dot change mat_nr for faces from left operand (they should be fine, because
materials aren't deleting by modifier)
- For faces from right operand check if needed material exists in left operand
and if so, use it's index as new mat_nr.
- If there are materials in right operand which doesn't exist in left operand,
they'll be changed to first material from left operand.
|
|
|
|
|
|
Original indices from right operand were used in boolean result derived mesh
which lead to crash if right operand has got more entities (faces/edges/vertices)
than left operand.
|
|
Issue was caused by left boolean operand consist of several intersecting manifolds
which make Carve triangulator confused and which can't be resolved in general case.
Added mesh pre-processing before actual applying boolean operator on it. This
preprocessing applies union operation on intersecting manifolds of the same object
so intersection edge loop with second object wouldn't confuse tesselator and correct
result would be returned.
Detecting of intersecting manifolds is based on AABB intersection check which leads
to some extra union operation called, but it's possible to speed things up from
Carve side so union operation of two not intersecting meshes would work faster.
Additional condition for running union for manifold is this manifolds intersects
AABB of second operand, so mesh topology wouldn't be changed at all in areas
where there's definitely no intersection between operands. It might be improved
so only manifolds which actually intersects second operand would be joined
together, but it'll slow things down a bit and prefer to do it only if it'll
be really a problem.
Additional change is fixed memory leak when boolean operation fails to run -
it was missed "delete" call if exception happens in Carve library.
From side effects of this change might be named boolean operation between
suzanne and another object: suzanne is consist of three intersecting open
manifolds, so this new meshes preprocessing leads to missed eyes in result
because of failure of merging two open manifolds. Don't think making suzanne
work for all setups should really be a goal, it's a bit crappy mesh for CSG
algorithms.
|
|
* CDDM_calc_edges --> CDDM_calc_edges_tessface
* CDDM_calc_edges_poly --> CDDM_calc_edges
|
|
rather then making an entire copy with CDDM_copy(result, 1)
|
|
|
|
inconsistent with similar functions & math notation:
mul_m4_m4m4(R, B, A) => mult_m4_m4m4(R, A, B)
mul_m3_m3m4(R, B, A) => mult_m3_m3m4(R, A, B)
For branch maintainers, it should be relatively simple to fix things manually,
it's also possible run this script after merging to do automatic replacement:
http://www.pasteall.org/27459/python
|
|
|
