This changes a bit the batches data structure. Instead of using one
vbo per material we use one for all material and use index buffers for
selecting the correct triangles.
This is less optimized than before but has potential to become more
optimized by merging the wireframe data vbo into the shading one.
Also the index buffers are not strictly necessary and could be just
ranges inside the buffer. But this needs more adding things inside
GPUIndexBuf.
Shaded triangles are not yet implemented (request from gpumaterials).
This also changes the mechanism to draw curve normals to make it not
dependant on normal size display. This way different viewport can
reuse the same batch.
The issue was caused by a special code in node tree freeing function
which will free extra fields in the case when tree is not in bmain.
This is how old code was dealing with "nested" trees, but is now
making behavior different from other datablocks. This is exactly
what was confusing copy-on-write logic.
Ideally, ntreeFreeTree() need to behave same as all other datablocks,
ad freeing of data of nested trees should be up to the owner of the
tree (this way it's all explicit and does not depend on check of
some special flag.
this can be different though (e.g. vertex parenting) and correct location
is already stored in ob->orig
spotted while looking into T59332
Reviewers: fclem, brecht
Differential Revision: https://developer.blender.org/D4076
This restores the object->data to a non-modifier evaluated state.
So this allow us to change evaluated object modifier stack directly and
get BKE_mesh_new_from_object() for the evalauted object.
Hex color values are now always in sRGB space, as would be expected by
most other applications. Previously they were in display space and using
the view transform.
In 2d655d3 the color picker was changed to use display space HSV values.
This works ok for a simple sRGB EOTF, but fails with view transforms like
Filmic where display space V 1.0 maps to RGB 16.292.
Instead we now use the color_picking role from the OCIO config when
converting from RGB to HSV in the color picker. This role is set to sRGB
in the default OCIO config.
This color space fits the following requirements:
* It is approximately perceptually linear, so that the HSV numbers and
the HSV cube/circle have an intuitive distribution.
* It has the same gamut as the scene linear color space.
* Color picking values 0..1 map to scene linear values in the 0..1 range,
so that picked albedo values are energy conserving.
In production files that use a lot of linking I measured loading speedups between 5% and 18%. In files that use less linking the speedup might not be noticeable at all, but it should not be slower.
Reviewer: brecht
Differential Revision: https://developer.blender.org/D4038
