Use tagging to avoid re-evaluating the same edges while sculpting.
While gives only minor speedup,
it allows for changes to the queue without additional redundant checks.
There should be no functional changes visible from this change, but this commit
should make it easier to code tools which need to check on tweeakmode status,
by making it easier to figure out which NLA Track contains the strip which
owned the action being edited. (The strip is already saved, so this commit just
adds the track alongside it).
For now there is no version patch for this. The worst that happens is that an
extra refresh is needed in the NLA editor to get these to show up.
With multiple strips in tweakmode, only the one tagged as being "active"
would get drawn in the correct colours, while all the others would just
get drawn as a selected strip instead.
When entering tweakmode on multiple strips (from different AnimData blocks)
simultaneously, only the track containing the last selected strip would be
shown. All the other tracks with strips being tweaked would not appear at
all.
To help make it more convenient to edit stashed actions, Shift-Tab
(i.e. holding down the Shift key, which "tabbing" into tweakmode as
usual to edit the action referenced by the active NLA strip) now flags
the NLA Track that the strip occupies as being "solo" too.
This allows you to use the NLA to select a stashed action, then Shift-Tab
to start editing it without any other actions in the NLA stack interfering.
Like the "Next/Previous Layer" tools in the Action Editor, this is designed
to help with checking on stashed actions.
editors.
Reporter used a hacky work-around by placing cursor at end of keyframe
range and doing ctrl-C ctrl-V repeatedly. This was working on 2.73 but
not anymore since the old selection is not kept.
Much better is to have duplication operator be repeatable. This commit
takes care of that.
Normal dragging now uses a precision of 0.01 instead of 0.1, shift+dragging now uses 0.001. (0.1 steps can still be done using ctrl)
Requested by @venomgfx
Transforming the center after transforming a handle would continuously
flush an extra offset to the handles.
Also use normalization range of -1.0 to 1.0 instead of -0.5 to 0.5 (not
really important, just for better comparisons)
Dyntopo can currently create skinny faces,
especially when the faces are much larger then the resolution.
To get the old behavior, set debug value to 1234
Use actual available number of threads now, which will make it easier
to increase max number of threads, without having some sloppy memory
usage and without doing some redundant checks on thread data which was
never used.
Allocate statistics array dynamically, so increasing max number of threads does
not increase sloppyness of the memory usage.
For the further cleanups: we can try alloca-ing this array, but it's also not
really safe because we can have quite huge number of threads in the future.
Plus statistics will allocate memory for each individual entry, so using alloca
is not going to give anything beneficial here.
The issue was caused by phase being limited from 0 to 1, which gave only
0..M_PI distribution which is not good enough for good randomness.
Now the phase is being randomized across full 0..2*M_PI range.
Using ctrl+LMB to collapse all panels except of the clicked one resulted
in an empty area if done from a view that is scrolled down to some
degree. Resetting the view makes this much better, although it still
doesn't work that well if the area is really small, but I don't think
it's worth over-complicating things here.
"Feature-Request" by @maxon ;)
Was using pointer hashing when the keys are in fact uint's.
Since they're well distributed from the rangetree,
no need to do bit-shifting tricks. just use int as hash.
Gives ~8% speedup in own tests.
