'Convert To...' Object operation has very weird effect of actually
working at obdata level, not object level, which means *all* objects
(even unselected/hidden/in other scenes/...) using same obdata will be
converted to new selected type.
IMHO this is very bad behavior, but... not a bug really, so do not
change this for now.
But at least, do not do that when working on some linked data, else it
leaves Blend file in invalid (incoherent) state until next reload.
So workaround for now is to enforce the 'Keep Original' option when some
linked object/obdata is affected by the operation.
Also fixed somewhat broken usercount handling in Curve->Mesh part.
Eeeeeek!^2 Calling unconditionnaly ID freeing `BKE_libblock_free()` on a
datablock (ob->data, i.e. Curve) that may be used elsewhere...
Veryveryvery bad!
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
New logic of split_faces was leaving mesh in a proper state
from Blender's point of view, but Cycles wanted loop normals
to be "flushed" to vertex normals.
Now we do such a flush from Cycles side again, so we don't
leave bad meshes behind.
Thanks Bastien for assistance here!
Finding which loop should share its vertex with which others is not easy
with regular Mesh data (mostly due to lack of advanced topology info, as
opposed with BMesh case).
Custom loop normals computing already does that - and can return 'loop
normal spaces', which among other things contain definitions of 'smooth
fans' of loops around vertices.
Using those makes it easy to find vertices (and then edges) that needs
splitting.
This commit also adds support of non-autosmooth meshes, where we want to
split out flat faces from smooth ones.
The issue seems to be caused by vertex normal being re-calculated
to something else than loop normal, which also caused wrong loop
normals after re-calculation.
For now issue is solved by preserving CD_NORMAL for loops after
split_faces() is finished, so render engine can access original
proper value.
We need to first split all vertices before we can reliably
check whether edge can be reused or not.
There is still known issue happening with a edge-fan mesh
with some faces being on the same plane.
Now new edges will be properly created between original and
new split vertices.
Now topology is correct, but shading is still not quite in
some special cases.
The change was delivering broken topology for certain cases.
The assumption that new edge only connects new vertices was
wrong.
Reverting to a commit which was giving correct render results
but was using more memory.
This reverts commit af1e48e8ab.
This includes a few fixes in the MBC_ api.
The idea here is for this to be the only interface the render engines
will deal with for the meshes.
If we need to expose special options for sculpting engine we refactor
this accordingly. But for now we are shaping this in a per-case base.
Note:
* We still need to hook up to the depsgraph to force clear/update of
batch_cache when mesh changes
(I'm waiting for Sergey Sharybin's depsgraph update for this though)
* Also ideally we could/should use BMesh directly instead of
DerivedMesh, but this will do for now.
Note 2:
In the end I renamed the `BKE_mesh_render` functions to `static
mesh_render`. We can re-expose them as BKE_* later once we need it.
Reviewers: merwin
Subscribers: fclem
Differential Revision: https://developer.blender.org/D2476
Original fix in this area was not really complete (but was the safest at
the release time). Now all the crazy configurations of slots going out
of sync should be handled here.
We *always* want to increase mat user count when from Object (and not
Data), because in that case we are moving mat from object to temp
generated mesh, material can never be 'borrowed' in that case.
To be backported to 2.78a
This is something what was guaranteed in give_current_material(), just
copied some range checking logic from there.
Not sure what would be a proper fix here tho.
Curves and meshes (when no modifier application required) would increase their material usercount twice.
Not sure how/why it worked in previous code, but with new, stricter ID handling we need more
careful check of ID 'ownership' handling.
Reported by Sergey over IRC, thanks.
Turns out most BKE_foo_make_local datablock-specific functions are actually doing
exactly the same thing, only two currently need special additional operations
(object and brush ones). So added a BKE_id_make_local_generic instead
of copying same code over and over.
Also, changed a bit how make_local works in case we are localizing a whole library.
We need to do the 'remap' step (from old linked ID to new local one) in the second loop,
otherwise we miss some dependencies. This fixes main part of T48907.
Note that issue has several levels here actually, first one was metaball's materials
not being properly copied into new mesh (code was commented out because of some crash it
seems, made it a bit closer to mesh one and got no crash at all...).
Then, we were calling test_object_materials when ob->data is actually *not* new tmpmesh!
Will remove this call completely in next commit (to make it easier to bisect), I cannot see
any case where object would be assigned with newly generated tmpmesh in this func.
This function was only a wrapper around id_clear_lib_data(), and shapekeys
are not linkable nor shareable anyway, no point keeping this currently,
was only adding confusion about shapekey 'status' as a datatblock.
Idea looked good, but we have too much custom situations here (some half-fake-sub-ID
being copied with their 'owner', animdata, etc.), let's let datablock copy functions
handle that themselves.
Also allows to safely call BKE_id_expand_local from all copy functions now (only when
copying linked data).
