Would free evaluated mesh even when it was the one cached in runtime
data by depsgraph evaluation!
Also fixes the asserts about using non-eval object in some cases.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Curve modifier eval code was actually doing nothing to ensure we passed
mesh with valid normals when required by the modifier.
This is a bit basic, rough code, but think it should cover all cases,
time will say...
The issue was caused by NaN valid of the average spring length being
stored in the file. This caused accumulation in the springs builder
to also deliver NaNs, which then caused solver itself to not do
anything.
Not sure why these values where never initialized prior to the
accumulation. Or even, why this runime data is stored in a DNA.
Some sanitizing is possible here, but needs to be done with care
to not disrupt Spring production.
In fact, we can get valid depsgraph 99% of time from current context.
Still added extra optionnal depsgraph parameter just in case (and also
for future, when we might be handling much more temp depsgraphs).
Now, things are becoming REALLY confusing. The script does build
pugi, but is never telling OIIO to use an external one. Which makes
it to use a bundled one.
Trying to link OSL to a different version of pugi causes a lot of
linking errors.
Interestingly enough, that was me who made OSL to use external pugi
to solve configuration problem. But now i can not reproduce that
anymore.
Ideally we would either link everything against our pugi, or not
compile it at all.
ARegion.sizex/y should never have DPI factor applied. For regular panel
regions, DPI will be applied in region_rect_recursive already, causing
it to be applied twice when region size is set dynamically (= based on
content dimensions).
The root of the problem is that KnifeTool_OpData->colors was not init in
some cases. But the reason is unknown as it seems to be random and the
init function was always called.
So instead on init the color only once, we query the colors each time
we draw the knife points.
The overhead of this approach is negligeable.
Allow more flexible use of drivers on B-Bone properties by
connecting the dependencies to the actual operation node that
uses the values, instead of the whole component.
