This is a beginning of series of commits which will clearly separate
building IDs which are used as object data from object building.
The goal is to be able to always build whatever ID. Required to make
driver targets to work reliably with copy-on-write concept.
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 ObjectID pass was generating per material per dupli a specific
number for the outline what results in a GPU context switch. In spring scene
01-050 a scene with many trees (duplis) generated 28000 GPU materials.
Now only new materials are created when objectid pass is enabled. Also
added a hard limit to the number of objects for the objectid pass (255)
Basically the outline between objects will not be drawn, but it will be
very hard to detect them also.
Also fixed for XRay mode.
Test this since the popup feels disruptive/flashing when its too large
when set smaller it looks closer to a menu w/ key-accelerators which is
the intention in this case.
It's also more likely the active tool can be placed under the cursor.
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.
Manipulators which aren't explicitly activated via tools are now hidden.
Tool manipulators are kept because it doesn't make sense to interact
with a tool with hidden manipulators.
Material slots are a real pain to get working, due to all the black
magic they do to hide object vs. obdata storage of the material...
Currently hitting an order problem - we need to always set 'link' (to
object or obdata) property of the slot first, before we set its
material... *super-sigh*
- 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.
