This commit is just a stopgap measure (i.e. it fixes the symptoms but not the
real underlying cause) of this bug. For some reason, iter->size is nearly always
an "effectively zero but not truly zero" value. Hence, the envelope sizes would
get adjusted, but would be scaled to an impossibly small value (taken from
iter->size).
From my investigations so far, iter->size is mostly either set to (or left as)
0, except in a rare case when dealing with volume snapping, when the values
somehow get propagated there from various intermediate data points. But, that
almost never works either.
Big thanks to Josef Meier (jomeier) for finding the fix!
It turns out that this was a case of variable shadowing that had been overlooked
and compilers were not warning about.
Apply patches in patches directory, remove patches that were applied
upstream.
If you made changes without adding a patch, please check.
Fixes [#32233] exporting bullet format results in corrupt files.
This adds border option to compositor, which affects on
a backdrop and viewer nodes, which is useful for faster
previews and tweaks.
Final compositing still happens for the whole frame, but
if it'll be needed it's not so difficult to support it
as well.
To use border there's Ctrl-B shortcut in the compositor
editor, which i used to define region you want to restrict
compositing to. There's also "Viewer Border" option in
the N-panel in case you'll want to disable border
compositing.
Some areas could be cleaned a bit, like ideally it shall
not be viewer image clearing in viewer_border_update RNA
callback, but currently it's not so much clear how to
make it the same fast as simple memset and glue it
somehow to compositor. Will think of nicer solution a
bit later.
Saving and loading gpencil was using different order for the individual list items.
On a 120 Mb gpencil project (yes, animators!) loading time went down from 1 minute
to a second or two.
Note that this to have effect, you need to save once.
Developer note: check this commit, it uses a new writelist function. You can
speedup stuff tremendously with keeping saved and read data in sync.
This is as close as I can get to keeping the old code intact. After this
commit, I will have to change existing code paths, making testing of
functionality harder.
Changes:
* Keep only projective texturing code in paint_image_proj.c
* Move 2D code to paint_image_2d.c. This needed the introduction of
allocation/cleanup functions for the relevant structures.
* Common code interface for both modes stays in paint_image.c (which
still includes all old code, system should work as it did with the
exception of non-projective 3D paint mode) and is made public. This is
not a lot of code, only rectangle invalidation and undo system.
* Changed the naming in the new code slightly: imapaint_ prefixed functions refer to
common functions used by both systems, paint_2d_ prefixed to 2d
painting. There will be an interface for the projection painting as
well. Probably there is some leftover naming conversions to do.
TODO:
* Move operator init/exec/modal to common interface file
* Get rid of old BKE_brush_painter_paint, now brush_painter_2d_paint.
All code uses stroke system for the stroke management
* Write space pressure management for the paint stroke system (for other
systems to access as well :) )
* Move texture paint tablet presssure exception code for old bugs to
stroke system (makes me wonder...aren't other systems also influenced by
these pressure issues?) or up in the function hierarchy inside texture
paint. This code is still not there so users with tablets may notice
some issues.
* possibly change other systems to pre-multiply pressure with the
relevant influenced attributes in the stroke function. This could get
tricky though and it's possible that it could backfire.
- activate from spacebar search (3D Ruler)
- ctrl-click adds new rulers
- clicking in the middle of a ruler, turns into protractor, dragging out of view snaps back to ruler.
Adding new file paint_image_proj.c which includes the projective texture painting part of texture
painting, using the stroke system. To access the new code path use Shift-LClick.
The new code path still is problematic with tablet pressure and I will be looking
into ways to unify this across paint systems next.
The old code is still present and can be accessed by regular Lclick as usual.
Also removed 3D (non-projective) painting from 3D viewport.
TODO:
* Add pressure influence code to stroke, remove from every other paint
system code, including texpaint.
* Put UnifiedPaintSettings update in PaintStroke code.
- Dopesheet need to be updated when adding or switching
between objects.
- After removing object it shall also be tagged for update,
otherwise crash will likely happen.
This was from initial BMesh merge, but should not have been added in since face normals are calculated and stored in the DerivedMesh.
Toggling editmode would remove poly-normals so its unlikely anything relies on this custom-data.
errors with the variables/targets, even if those errors are for variables which
aren't used (and are hence "harmless" errors)
This means that the filter can be truly useful for helping locate things that
need "cleaning up". For example, previously, there could still have been drivers
where there were some of these "harmless" errors would emit warnings, but would
otherwise appear perfectly functional.
The implementation here uses a slightly slower method of checking any errors in
these driver vars. However, it's no slower than what's done when these are
evaluated, and should be less error prone than introducing yet another type of
error tagging for this one case. The problem here is that the "driver invalid"
flag, which is usually set when a target has errors, gets cleared by the
pydrivers code if nothing went wrong when evaluating the expression. Removing
this clearing step will probably open a can of worms, so unless this method
proves to be far too slow, this simpler fix will do.
you to fix the RNA Path in-place
For F-Curves that are disabled or marked as having errors because their paths
are invalid (indicated with a red line underneath their names), it is now
possible to use the Ctrl-Click renaming functionality to bring up a textbox for
fixing the offending RNA Path "in place" (i.e. in the channels list) without
having to bring up the properties region first.
This makes it easier to fix the paths if you know what you're doing. However,
caution is still advised for most people. In particular, be aware that this uses
a separate "RNA Array Index" for indexing into array properties (i.e. location,
rotation, color) which will not be shown here, and can only be edited from the
panel (or datablocks editor/scripts).
F-Curves/Animation as well as Drivers
This is useful for tracking down invalid F-Curves which might need to have their
paths fixed, or perhaps to remove F-Curves for controls which no longer exist in
a new rig.
