This commit adds a confirm threshold property to pie menus.
Basically, this will confirm the pie menu automatically when
the distance from the center of the pie exceeds that threshold without
a need to release the pie button.
The confirm threshold will only work if it is larger than the pie
threshold.
The confirmation actually occur when the mouse stops moving, to
allow multiple pie menus to be better linked together, (see below)
This functionality also facilitates the ability for chained pie menus by
dragging. Basically, a pie menu item can be a call_menu_pie operator and
the new pie menu will still use the original pie menu release event for
confirmation. This should allow for quick, gesture based navigation in
pie menu hierarchies (going back in the hierarchy is still not supported
though)
There will be a demonstration pie in the official add-on soon
* Consider non-manifold edges as sharp, as in split normals handling.
* Consider edges from sharp polys as sharp!!!
* Fix returned number of groups (was off-by-one for non-bitflags grouping, could also
be wrong in case of id overflow).
Note about using sharp polys too to define groups: Only current use of this function
(Obj exporter) does not need that, because it does its own check for sharp faces.
However, we might reuse that func in other places in future (e.g. in custom split
normals area), so better to get a consistent behavior!
Navigation mesh object need to access the current scene at
creation time. This can be at scene start or when an object
is instantiated from an inactive layer. The method of getting
the scene differs in these cases. This fix handles both.
Issue was, parenting with operator, then unparenting would keep the inverse parent matrix.
So if you then parented again through the mere Object field of Object buttons, you'd still
use previous inver parent matrix, giving some weird behavior from user PoV.
This commit simply makes sure inverse parent matrix is always reset to indentity when clearing
parents.
In drag style pie menus clicking is ignored now. This is done because
if we want to ensure that pie menus will not respawn, we had to not
destroy and keep the pie menu invisble while the button is pressed.
This opened a can of worms where pie items that would spawn popups could
steal the focus from the invisible pies and then the former pies would
be stuck in an invisible state, stealing all input unless user did a
right click to cancel the pie.
Invisible state is still kept for cancelling and strictly for that only.
This still allows nested layouts but only in click style, while hold
style is used for faster interaction. As a plus, it should also be
possible to tweak slider properties now, though menu will close after
that.
quit.blend.
This will use a slower file write if an object is in edit or sculpt
mode.
Autosaving will explicitly not be supported to keep it fast.
Added a tooltip warning.
A StrokeVertexIterator ignores the first element when it is the only element.
Such an iterator can be created by the .incremented() method from an iterator
over two stroke vertices.
This problem is a regression from 2.71. The present fix is appropriate to backport
if Blender 2.72a is planned.
Problem report by Kazuhiro Murakawa through personal communications, thanks!
Not as if it gives any huge benefit to end artists, but it's kinda silly
to have like 3 different task/thread scheduling systems. The new one is
what's recommended for use now i'd say.
On the other hand it has unmeasurable memory save benefit :)
Basically, this commit changes pie menu click interaction so that
confirmation is done on left click release instead of press. This allows
dragging on the pie menu to select different items, but most
importantly, there should be no left over click events passed on to
subsequent menus/pies. This means that pie menus should now be able to
spawn popups safely. Also, left clicking to spawn a second pie menu now
sets that menu to click style by default allowing for better interaction
between hierarhies of pie menus.
Two fixes here (only the second one is strictly needed to fix the issue,
but both make the system better).
First is introduction of a random generator array for use with threaded
systems where each thread needs to access its own number generator.
The random texture now uses this so it should not be influenced by other
random generator reseedings of the main random generator like it did
before.
Second, I reshuffled the texture code to resample the upper bits of the
random number first. According to Numerical Recipes, this is where the
most variance can be found, so by sampling those we avoid correlation
issues. Also, multiplying here is not ideal because if a pair of bits
are zero, then the whole result will also be zero.
Overall this is much more random (tm) than before, however result will
also be brighter, since we now have less black spots. Tweaking the
brightness/contrast should somewhat fix that, generally having the same
result as before is not possible anyway if we are to really fix this.
Also, seems like exposing procedural depth might be nice here since it
influences the precision of the texture lookup.
Basically the title tells it all, quite straightforward implementation.
The only thing is the image.render_slot which used to represent the active
render slot index is now moved to image.render_slots.active_index.
Reviewers: venomgfx, campbellbarton
Differential Revision: https://developer.blender.org/D821
This patch removes several stroke shaders written in C++ that are unused
and don't serve a real purpose any more. The removed shaders are:
- BPy_ColorVariationPatternShader
- BPy_StrokeTextureShader
- BPy_TextureAssignerShader
- BPy_ThicknessVariationPatternShader
- BPy_fstreamShader
- BPy_streamShader
and a few more that weren't even exposed to the Python API.
Some minor edits were made by the reviewer.
Differential Revision: https://developer.blender.org/D801
Reviewed by: kjym3
This way it is possible to define render border directly from the image editor,
which is useful for at least three things:
- If viewport is really optimized out (simplified etc) then it might be hard to
guess which exact area you're mainly interested now.
- No need to switch to the viewport to do render border tweaks, could be useful
when doing compositing.
- If one need to look at particular pixel(s) which is real handy for debugging
render engines (both Cycles and BI).
Reviewers: campbellbarton, venomgfx
Reviewed By: venomgfx
Differential Revision: https://developer.blender.org/D820
