The motion actuator goes out of its way to prevent setting zero velocities,
which should actually be supported. This patch just works around it as a
first test. We should investigate whether the flags
`m_bitLocalFlag.ZeroLinearVelocity` and `m_bitLocalFlag.ZeroAngularVelocity`
are actually needed/desired at all.
One of the issues that's already visible with this simple change, is
that objects aren't actually frozen but still move a little bit; see
test with {F241908}.
Reviewers: lordloki, hg1, moguri, panzergame
Reviewed By: lordloki, panzergame
Differential Revision: https://developer.blender.org/D1545
Looks like UI code can produce widgets with same left/top positions (in very narrow space case).
Not nice, but we do not really care, UI becomes unusable way before we reach that point anyway.
RNA could define strings as dynamically sized,
but the interface ignored this and clamped them to UI_MAX_DRAW_STR.
Fixes T46734, also fixes possible pasting non-utf8 text into utf8 buttons.
We have callbacks for that, they also do some checks and help ensure things are done
correctly. Only place where this is assumed not true is blenloader (since here we
may affect refcount of library IDs as well...).
USER_ONE was only ensuring id->us was non-zero, while USER_REAL ensures
it is non-zero **and** >1 in case fake_user flag is set (which at least
ensures us unsetting fake_user won't leave id->us in invalid zero state).
As we can see in (original) read code, ob pointer in groupobject is actually a 'USER_ONE' case.
This was not done in 'add object to group' code, probably because we can assume objects always
have at least one user in that case? Made it explicit now. Also fixed foreach_ID_link looper.
In general we have waaayyyyyy too much 'own handling' of ID->us count in code currently,
will clean up that...
(if they're on different properties).
This patch basically gets rid of (ui-related) hack where we was adding specific
'fake' enums for datatypes needing additional options.
That was done because of broken UI code - to summarize, 'align' code did not support
correctly layout mixing vertical and horizontal sub-layouts, in particular if
it was 'column-major'.
A complete rewrite of this align code has been done, so now we can use a more
sane UI code.
This new code fixes a tons of issues with previous one, which basically was epic-failing
in many non-basic cases (especially mixed columns and rows with column-dominant layout).
It basically no more relies over order of buttons declaration in the uiBlock, instead it
finds and stores spatial neighbors and uses that data to compute needed stitching.
See code comments for details.
New code seems to be roughly ten times slower than old one (for complex grouped layouts),
that is, about a few microsecconds per alignment group - this remains reasonable.
Also, ui-align code becomming rather big in itself, it was separated in
own new `interface_align.c` file.
Reviewers: campbellbarton, severin
Reviewed By: campbellbarton, severin
Differential Revision: https://developer.blender.org/D1573
This commit makes drivers on node groups to with when using new dependency graph.
Still TODO: Need a relation between drivers and tree evaluation perhaps, so we
guarantee proper order of all operations.
Darkens the colors for limit and mist indicators of non-active cameras. This makes it easier to see which indicators belong to the active camera and which don't.
Useful for layouts with multiple cameras.
Requested by the Caminandes team.
Custom-data on newly created face data was often rotated.
Now the API doesn't copy data from adjacent loops when creating faces.
Most functions were already overwriting this anyway.
Since such decisions are better made at a higher level, now it's the responsibility of the caller.
This is really similar to what GPU module was already doing. There are number of
possible improvements still:
- Re-use allocated VAOs when requesting new ones instead of going to the trouble
of freeing VAO and then re-creating it again.
- Move VAO handling to GPU module.
Fixes T46589: OpenSubdiv crash with drivers
There is no real elegant solution here, ideally a modifier shall never *modify*
a source DM, but that would imply much better ways to ensure required data
is available in that source DM, which we do not have currently.
So instead, let's use brute force solution for now and always create a local copy
of our source DM, that we can modify to our heart content!
