Blender Git Loki

disable normalize when active vertex contains locked weights

disable vertex editing when weight group is locked

quiet double promotion warning and some style cleanup

Fix #35546: clicking cycles "Use Nodes" did not do a proper undo push, due to
button disappearing as soon as it's clicked. Workaround now is to make this an
operator. Thanks to Lukas and Campbell for tracking this down.

Fix #35846: crash rendering with dupligroups visible in 3D viewport during render
in some cases. The dupli code would still do object updates during render indirectly,
while this is disabled for thread safety everywhere else, now we disable it for this
case as well.

Not a pretty solution but this is for the depgraph refactor to solve.

Fix #35824: finding missing files not working correct for filepaths with special
characters on Windows.

Replaced some uses of stat() by BLI_stat() to properly handle such filepaths.

correct assertion error (clear dirty normal flag when there are no vertices)

Fix part of #35859: lib linking errors were not shown when opening files through open recent.

Fix #34909 Texture paint mode does not correctly update when using
textures larger than 2048x2048.

Check if texture is over user preference or GPU limit in texture paint
mode and if it is, scale the partial redraw rectangle before uploading
to GPU. This should be faster than rescaling the whole texture.

Fix #35715: graph editor > channels > move.. menu item showed wrong keyboard shortcut.

patch [#35830] Add Catmull-Rom spline as an option for lattice deformer

style cleanup

new weight operators had zero min/max range for the 'weight_group'

Use bit-shift op for all bit-flags.

Btw, there is a comment stating that bits 12-15 are the same for uiBlock->flag and uiBut->flag, this is obviously no more true currently (maybe it is now bits 14-17, i.e. ALIGN flags?).

Merging r57726 through r57728 from trunk into soc-2013-depsgraph_mt

Include DNA_scene_types before ED_object instead of forward enum declaration

Forward enum declaration is a bad idea, especially for C++ which requires
enum specification to dteermine which data type to use to store it.

Alternative would be to not use enum as an arument and pass it as int,
but actually would rather be strict on typing -- using explicit enum
as parameter type helps understanding the code and prevents possible
mistakes when using the function.

Experimental feature to lock the interface while rendering

Added function called WM_set_locked_interface which does
two things:

- Prevents event queue from being handled, so no operators
or values are even possible to run or change. This prevents
any kind of "destructive" action performed from user while
rendering.

- Locks interface refresh for regions which does have lock
set to truth in their template. Currently it's just a 3D
viewport, but in the future more regions could be considered
unsafe, or we could want to lock different parts of
interface when doing different jobs.

This is needed because 3D viewport could be using or changing
the same data as renderer currently uses, leading to threading
conflict.

Notifiers are still allowed to handle, so render progress is
seen on the screen, but would need to doublecheck on this, in
terms some notifiers could be changing the data.

For now interface locking happens for render job only in case
"Lock Interface" checkbox is enabled.

Currently this option would only make rendering thread-safe, but
in the future more benefits are possible to gain from it. Namely,
if we'll make renderer using it's own graph, this option would
allow to free memory used by 3D viewport graph, which would help
keeping memory usage low (or even would allow renderer not to
copy anything in this case).

Initially thought this change will also allow to free DMs used
by viewport, but we couldn't actually do this. This is because
of modifiers which uses other objects (like boolean), They're
in fact using viewport DM. This is bad because of few reasons.

We currently need to have viewport DM when rendering.
And for sure even in background render viewport DMs are being
calculated. This sounds like 2x computing is needed: one is for
viewport DM and one is for RenderDM.

If we'll have local graphs, we'll be able to compute RenderDMs
only and store them in graph. This would require a bit more of
the memory, but would solve current issues with viewport DM
used for modifiers operands while rendering and it should give
quite noticeable speedup.

Other tools like backing would also benefit of this option,
but rather get approval of current way of locking first.

Merging r57695 through r57725 from trunk into soc-2013-desgraph_mt

Fix typo made back in svn rev35785

Callback handle was assigning to wrong storage in RE_draw_lock_cb.
So far it was completely harmless because all the callbacks are
using the same handle, so test_break_callback was using correct
handle, and since draw_lock_callback didn't use handle at all
nobody noticed this.

But this typo lead to draw_lock_callback using NULL instead of
real RenderJob, which is bad for the feature we're working in
GSoC branch.

Buildbot: disable command length workaround for now, seems to give link errors.