Most of them are harmless implicit conversions (e.g. Alembic deals with
doubles for storing time information when Blender uses both ints and
floats/doubles) or class/struct mismatch on forward declarations.
This aims at always ensuring that ID.newid (and relevant LIB_TAG_NEW)
stay in clean (i.e. cleared) state by default.
To achieve this, instead of clearing after all id copy call (would be
horribly noisy, and bad for performances), we try to completely remove
the setting of id->newid by default when copying a new ID.
This implies that areas actually needing that info (mainly, object editing
area (make single user...) and make local area) have to ensure they set
it themselves as needed.
This is far from simple change, many complex code paths to consider, so
will need some serious testing. :/
Was a ground work for some more improvements here, but got dragged
to some other studio maintenance job here.
The plan would be to enable exposure/gamma control for fallback mode
which will definitely be really handy for development and might be
handy for cases when OCIO config can not be read.
Crash is due by mismatching loops and faces counts between the Alembic
data and the Blender derivedmesh which does not appear so
straightforward to fix (the crash happens deep in the derivedmesh code).
So for now, try to detect if the topology has changed and if so, both
only read vertices (vertex colors and UVs won't be read, as tied to face
loops) and add a warning message in the modifier's UI to let the user
know.
The idea is simple: cache PD resolution from cache_point_density() RNA
function because that one is supposed to be called while database is
locked for original synchronization.
Ideally we would also pass array size to the sampling function, but
it turned out to be quite problematic because API only accepts int type
and passing size_t might cause some weird behavior.
This is a way to avoid possible memory corruption when render threads works
in parallel with UI thread.
Not guarantees complete safe, but makes things easier to check anyway.
This fixes multiple problems on latest Mac OS + Xcode. Hopefully does not cause any on other platforms.
The Xcode detection logic could use further cleanup. It's checking several old versions that are unsupported for Blender 2.8+ development.
Needed because deps graph can destroy objects from any thread. We ran into the same problem & solved it in GPU_buffers.
Implemented in C++11 since it provides the needed machinery. The interface is in C like the rest of Gawain.
This means editing a property will now always affect all selected objects, bones or sequencer strips. Support for this was added in rBdfbb876d4660 but you had to hold the Alt-key to use it. The old behavior of only editing the active object will not be kept like decided in the 2.8 workflow meeting (reports comming). If you only want to edit the active object, you have to deselect others.
There are still a couple of issues to be resolved (listed below), but having it enabled by default helps testing and getting used to it and should motivate us to fix them ;)
To be fixed:
* Give users hint when edits are applied to all objects/bones/strips ("Applying to x objects") - there are ideas but we need to finalize and implement them
* Make it work better in corner cases (material editing, modifier property editing, etc)
Note: Values usually override the initial value of the object/bones/strips, except of number buttons where it depends if you enter the value (absolute override) or drag the value (add value change). This behavior is consistent with multi-button editing.
To bring the API more into line with the UI (and the general expected behaviour of
Blender when it comes to adding stuff), newly created layers and palettes will be
made the active ones by default. It's possible to override this behaviour still
(e.g. in cases where you're auto-generating a large number of them), but otherwise,
this change will help prevent errors like T50123.
When there were no prior palettes, creating a new one didn't automatically make it active.
This caused problems when trying to rename the color, as the RNA code assumed that if there's
a color, it must come from the active palette.
This commit partially fixes the problem by ensuring that if there are no palettes, the first
one will always be made active.
- Remove 'rotate_m2', unlike 'rotate_m4' it created a new matrix
duplicating 'angle_to_mat2' - now used instead.
(better avoid matching functions having different behavior).
- Add 'axis_angle_to_mat4_single',
convenience wrapper for 'axis_angle_to_mat3_single'.
- Replace 'unit_m4(), rotate_m4()' with a single call to 'axis_angle_to_mat4_single'.
This is no longer needed since moving to MPoly/MLoop data structure.
Also use 3x3 matrix for transforming instead of quaternion
(slightly better performance).
Was giving huge artifacts in the barber shop file here in the studio,
Maybe not fully optimal solution, but committing it for now to have
closer look later.
All objects were being parented to a single instance of each parent
object, instead of their respective instances, when using dupliverts or
dupligroups.
Behavior was caused by the `persistent_id[0]` (vertex/face id) being
ignored when computing `parent_gh` hash, which caused all instances to
have the same hash, and thus only the first one was included.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D2370
