That was indeed not working properly, not at all. Except for
the basic case, but as soon as you used another object to define the
mirror plane, it would be utterly broken, in several different ways!
Exiting modes shouldn't be needed since loading the new memfile
will free the old data.
Sculpt mode dynamic topology was adding undo data on exiting the mode
which isn't logical in this case and can be avoided altogether.
- When toggling a mode that doesn't support multi editing
only do this once of the active object.
- For sculpt mode create sculpt data since this is needed
for activating other sculpt objects on reload.
This reverts commit 4d8ed937f2.
An alternative fix will come soon as a patch, since this introduced an issue.
Rolling back since the original fix (sculpt cursor on load) is less important
than the issue it introduced (crash on weight paint undo/redo).
Fix T60322.
We now perform COW -> original data flushing for all the debug values + error
status flags on Drivers/DriverVariables/DriverTargets, as these are only set
when errors are encountered when evaluating drivers.
When BPY_python_end() is not called, there can be buffered data still in
`sys.stdout` or `sys.stderr`. This generally isn't an issue when those are
connected to a terminal, but when they are read by another process (in the case
of rendering with Flamenco, for example) we could miss the actual error message
that's causing the exit in the first place.
The following script demonstrates the issue; before this commit neither the
writes to STDERR and STDOUT nor the traceback of the NameError were shown.
#!/bin/bash
cat > file-with-errors.py <<EOT
import sys
print('THIS IS STDERR', file=sys.stderr)
print('THIS IS STDOUT', file=sys.stdout)
nonexisting.monkey = 3
EOT
blender --enable-autoexec -noaudio --background \
any-existing-blendfile.blend \
--python-exit-code 42 \
--python file-with-errors.py 2>&1 | cat
Reviewers: campbellbarton, mont29
Reviewed By: campbellbarton, mont29
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4168
This switches evaluation of vertices which are on the boundaries
of PTex faces to a single threaded one. While this introduces
some slowdown it fixes ambiguity of PTex index used to evaluate
particular vertex.
Possible alternative solutions would be:
- Do some pre-calculation of index, then do evaluation in threads.
- Try using Gregory patches and see if that makes any affect.
Fix T60235: Flickering of object instances
