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
The solution is to do the multiplication with the energy in the shader
after texture application.
We might be able to avoid setting dyncol completely, but this needs
better investigation. Some shader paths also look a bit redundant.
Also, texture mapping is not supported very well for light lamps, might
also need investigation.
