Recent changes to blendfile reading adding deferred reading of actual
data broke it, we cannot use the nifty `bhead + 1` to access data
anymore, since there is no guaranty that that block hass been fully
read.
Note that there is still one case in `read_file_thumbnail()`, however
loading of blendfile preview itself seems to be working fine... Maybe
@campbellbarton can double check that point (or knows of hands whether
it is OK there)?
Some uninitialized colormanagement data was breaking RNA acces for them,
exposed in batch preview management when generating previews for scenes
because we have to backup/restore scene and all its settings
before/after rendering it...
Make sure we don't reallocate arrays in the pointcache when not needed, the
size of a memory allocation can be slightly bigger than the requested size.
Also, use consistent check for shared cached in copy and free functions.
During screen to workspace/workspace-layout conversion, the first layout
of each workspace would be activated. For temporary full-screens, this
used to be the full-screen layout (IIRC), apparently it's now the
the layout to return to on "Back to Previous". So the 'previous' layout
would be activated, not the full-screen one.
When actually pressing "Back to Previous" now, the operator would first
free the active layout (which it assumes to be the temp full-screen -
wrongly in this case) and then try to activate the non-full-screen one,
causing use-after-free.
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
Do not force to link indirectly linked collections into current scene,
that is usually not desired. Note that user can always add this link
manually if they want.
All this 'implicit instantiation' post-linking process is rather hairy
to get it correct, hope this time it's not breaking something else...
Requested by some users who prefer old wireframe precision.
Smooth wires are still enabled by defaults as they don't have a noticeable
perf impact.
Application restart is needed for changes to take effects.
Use 'size' instead of 'len' to represent the size of data in bytes,
'len' is used for the result of 'strlen' or the length of an array
in some parts of 'makesdna.c' & 'dna_genfile.c'.
Also clarify comments and some variable names, no functional changes.
Now always refresh when the material changes. Depsgraph tag moved out
of the refresh function since that gets called on depsgraph update,
which should not trigger a second depsgraph update.
As discussed with @billreynish this makes little sense now that we don't
have a dedicated textured mode. We don't have a superior texture or shaded
mode anymore and we also cannot mix different engines together (workbench
with eevee/lookdev).
The only feature it removes is the possibility to hide textures for certain
object in solid mode.
Avoids mixing these in with regular variables in code-completion.
Use char for pad members except for 'void *', to make size clearer.
Removed/shrink a few redundant padding vars which were >= 8 bytes.
While Buffering output is useful for file writing and memfile
compression it's redundant when the output is already buffered.
It doesn't make a significant difference for ZLIB
however it makes a moderate improvement for LZ4, see T56162.
The option is separated from the solid mode color option.
Random color uses the same method as solid mode.
Selection state is indicated by a brighter color that is outside the
brightness range of the unselected state colors. The active state is
indicated by the outlines that is, now, still drawn in wireframe mode.
Coloring of the selection / active outline is not optimal because it
can look ugly in some cases of color combination. But the outline color
is using index range coloring so it's not trivial to change the color of
the outline per object. For now we use the same outline color used in solid
mode for consistency and also still add an emphasis on the selected objects.
The Single color option uses the theme color. Maybe it would be nice to
change the name of it in a latter commit to avoid confusion.
