Age | Commit message (Collapse) | Author |
|
Conflicts:
source/blender/editors/space_view3d/drawobject.c
|
|
|
|
Note: Depsgraph still calls the nodetree eval function that doesn't
nothing in turn. We can remove it, but it is harmless though.
|
|
Derivedmesh.
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.
|
|
This introduces a garbage collection system similar to gpu_texture.
|
|
Similar to recent sculpt mode.
|
|
The assert should only be triggered when assigning a pointer, and not
simply when checking the pointer.
|
|
It has nothing to do with ob->derivedFinal, which it checked before.
|
|
number of pbvh vertices.
This shall help catching issues in future.
|
|
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).
|
|
|
|
Sometimes one needs a *lot* of changes for a single G.main... :/
|
|
|
|
- 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
|
|
|
|
|
|
Conflicts:
source/blender/editors/sculpt_paint/paint_vertex.c
source/blender/editors/sculpt_paint/sculpt.c
source/blender/editors/sculpt_paint/sculpt_undo.c
|
|
|
|
|
|
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.
|
|
|
|
|
|
This caused crashes in some cases, and should be fully handled by
the depsgraph now.
|
|
|
|
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.
|
|
This causes a temporary spike in memory usage when creating a copy; the
entire copy will be removed anyway when DerivedMesh is removed.
|
|
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).
|
|
Code shared between BKE_mesh_new_nomain() and
BKE_mesh_new_nomain_from_template() is now in separate functions, instead
of copy-pasted.
|
|
The totxxx fields should match the number of elements in their respective
custom data layers.
|
|
This maintains the `BKE_mesh_` prefix for the mesh-related BKE functions.
|
|
Those functions were using DerivedMesh but are not called from anywhere.
As a result, they cannot be tested after porting DerivedMesh to Mesh.
|
|
Functions that are no longer in use can be marked as such, so that later
we can easily remove them.
|
|
Mesh
The function still returns a DerivedMesh, but internally it uses Mesh
now.
|
|
|
|
Regression in 481cdb08ed6f3
|
|
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/blendfile.c
source/blender/blenloader/intern/readfile.h
source/blender/blenloader/intern/versioning_250.c
source/blender/blenloader/intern/versioning_260.c
source/blender/blenloader/intern/versioning_270.c
source/blender/blenloader/intern/versioning_legacy.c
source/blender/editors/render/render_shading.c
source/blender/makesrna/intern/rna_movieclip.c
source/blender/render/intern/source/pipeline.c
source/blender/render/intern/source/voxeldata.c
|
|
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.
|
|
|
|
Caused glitch w/ sculpt mode not updating.
|
|
- users can use their own matcaps
.config/blender/2.80/datafiles/studiolights/matcap/ folder
- upto 100 matcaps can be loaded
- color of the matcap is influenced by the color of the material/single
color etc. To show the plain matcap use single color at 1.0
- chosing a matcap is at lighting level (flat/studio/matcap)
- matcap only possible in solid mode
- also works for X-Ray mode
As the old matcaps are still in used by the clay engine I didn't remove
it yet.
|