Pretty straightforward changes, merely mimicking dm-related code,
which was already essentially using either Mesh or BMesh data to
build the PBVH...
Note that we "lose" the subsurf (a.k.a. grid) PBVH case here, but that
one was already dead code in current blender2.8, since final dm is
always a cddm built from evaluated mesh.
Proper fix is pending new code for subsurf/multires area.
When a CacheFile datablock is copied to an in-main datablock, it means that
the new copy should be independent of the old copy. In this case certain
properties are reset/duplicated. When it is copied to a no-main datablock,
we assume this is a copy-on-write copy that's used for evaluating things,
in which case the handle and object paths are referenced instead of
reset/ duplicated. This prevents us from re-opening the Alembic file every
time a new CoW copy is made.
The same approach is taken when freeing data (only when an in-main datablock
is freed do we actually free the data).
- all known image types are supported
- BpyAPI for studiolights added
- added open user pref operator in shading menu
- possible to add multiple files in a single run
For now refreshing studio lights will free all studiolights and reinit
the whole mechanism. This can be improved by only freeing deleted, reset
updated and add new custom studiolights.
details to show currently only shows the path we perhaps want to add
other information also
Before that copied collection in copy-on-write were running out
of sync with original ones. This was causing crash with the
following scenario:
- Delete some objects from scene
- Add particle system to an object
- Change particle mode to Hair
Thanks Dalai for debug session! Pair programming ftw!
The issue is that children drawing is done by object mode,
which operates with data from evaluated context. But that
data needs edit mode's cache to be properly updated first.
Makes ADD brush to work.
At some point children particles draw got broken, children are not
visible for until first stroke is done. Still looking into it.
The mutex was shared between CoW copies of the CacheFile datablock, and
as a result also freed multiple times. It is now only freed when the
original datablock is freed; the CoW copies share the same mutex.
DATA datablock must evaluation must never depend on object it is
used for. If there is something what depends on an object, it must
be done on object level.
At least the actual callback was empty.
When the source mesh doesn't have the primary layers (CD_VERT for vdata,
etc.) the returned mesh also didn't have those layers, even when non-zero
elements were requested (for example requesting 4 vertices would still
result in mvert = NULL).
The function definitions still reside in DerivedMesh.c. Once we're done
porting all the DerivedMesh use to Mesh, we'll move the still-relevant
functions to mesh_runtime.c. This move is now cumbersome due to shared
statically-declared utility functions in DerivedMesh.c
This helps making things clearer and cleaner. Func returning filepath of
G.main is separate, so that we can easily track its usages, and
hopefully deprecate it at some point. Though that usage of G.main is
likely the less evil one, you nearly always want current blendfile path
in those cases anyway.
