Mainly 'X' icon for Delete, which was already on modifiers and constraints,
but not for objects. Select icon for object selection and refresh for library reload.
Originally, when transferring all source data layers to destination
meshes, code would abort in case destination did not have all needed
layers, and creating them was not allowed.
Now, it will instead transfer data to layers that exists, merely
skipping source ones for which it cannot find a matching destination.
Some developers were using undo for their scripts, this allows for undo
pushes in background mode, however - as with 2.7x, undo isn't
initialized at startup in background mode.
See replies to T60934
As far as we know this wasn't widely used, and relied no storing data
in the temp dir which may be cleared on reboot.
More generally, alternative behavior for a core area like file IO
is not something to keep if it has unresolved issues.
See D4310 for details.
That guy was still from the era where only way to remove an ID was to
save & reload the .blend file. Use modern code instead, should also be
much, much more efficient in big production files.
And that’s another nice occasion to add/test new batch ID deletion code, too. ;)
Related to T61276 Make Single User unlinks original object.
This avoid edges covering a part of vertices.
This comes at a (very minor) perf cost as vertices can cover some edges
pixels and early discard them with the depth test. But this only happens
in artificialy dense mesh and is not a real problem for common cases.
This make sure only one line is drawn per edge.
It makes the function mesh_create_edit_loops_points_lines() non-thread safe
but this is fine as of now because nothing is multithreaded at this point.
Also this is the only function use this flag so it might be OK.
The side effect is that we don't need to use depth test in edit mode
overlay so the masking artifact will not appear.
This make it (theoriticaly) compatible with all supported hardware with
consistent results.
Also we now draw the lines with analytic anti-aliasing instead of relying
on MSAA (which offers less benefits in our case).
The remaining aliasing comes from edges cut in half by the mesh which is
not rendered with MSAA. Hopefully this is not too much distracting and only
happen if the face is almost parallel to the view.
Is available when doing "View -> Show Metadata". Will draw all the
fields which are not part of the stamp at the bottom of the image.
Couple of hand-picked fields are ignored, since those are not very
useful to be seen.
Aimed to ease review of rendered shots.
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4316
Is a missing do-verisoning code in e3d31b8dfb.
Unfortunately, at this point it is rather tricky to tell old and new
hair dynamics modifiers apart. Probably easier to accept possible
breackage of the files which were created in 2.7 and saved during
2.8 which had incomplete do-version code.
This is a follow-up to rBb44e6f2b3d32, for some reason that issue was
not detected back then: in some cases, DEG_iterator_objects_next() will
free the temp list of dupli objects once it does not need it anymore,
henceforth freeing the dupli_object_current memory of the DEGObjectIterData
that we are storing in the RNA_Depsgraph_Instances_Iterator struct.
And yes, the uglyness of that hack is getting even better now...
Found while trying to export dupliobjects with FBX...
Note: We still change it to the collection we are directly isolating/making
visible and its parents (in the case of isolating). But no longer its children.
Feedback and discussion on D4011. The motivation is that if we don't keep those
locked the disable state becomes useless.
Was introduced by point cache reset on manual edits. Needed to
split evaluation and introduce an explicit init key, which allows
to hook up relations which are "monitoring" manual edits to the
channel.
Noticed while looking into T61190.
Was visible with certain configuration only, is a numeric
instability caused by degenerate ray direction.
Not sure the distribution is correct, just fixing crash
which was caused by usage of watertight intersection.
This is a request by the studio here to make it possible to see how
many samples were used to render a specific shot or a frame. It is a
bit more tricky than simply stamping number of samples from a scene
since rendering is happening in multiple ranges of samples.
This change makes it so Cycles saves configured number of samples for
the specific view layer, and also stores start sample and number of
samples when rendering only a subrange of all samples.
The format used is "cycles.<view_layer_name>.><field>", which allows
to have information about all layers in a multi-layer EXR file.
Ideally we can store simplified "cycles.<field>" if we know that there
is only one render layer in the file, but detecting this is somewhat
tricky since Cycles operates on an evaluated scene which always have
single view layer.
The metadata is shown in the Metadata panels for clip, image and
sequencer spaces.
Example screenshot which shows the metadata:
{F6527727}
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4311
