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.
Object visibility is now handled by the depsgraph iterator, but this API
was incomplete as it made no distinction for visibility of the object itself,
particles and generated instances.
The depsgraph iterator API now includes information about which part of the
object is visible, and this is used by Cycles to replace the old custom logic.
Cycles and EEVEE visibility should now be consistent, which unfortunately does
means some subtle compatibility breakage for both.
Fixes T58956, T58202, T59284.
Differential Revision: https://developer.blender.org/D4109
The issue was caused by shape keys datablock from evaluated mesh
being added to the main database.
This commit makes it so shape keys are not copied for the mesh
used as cage.
We were never removing the parent collection from a collection upon removal
of the parent.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D4099
There is no point having operations that iterate over the whole
bit array as macros, so convert BLI_BITMAP_SET_ALL to a function.
Also, add more utilities for copying and manipulating masks.
Reviewers: brecht, campbellbarton
Differential Revision: https://developer.blender.org/D4101
This commit makes it so curve path parent solving accepts an explicit
arguments for both time and curve speed flag, making it so we don't
have to mock around with scene's frame.
One unfortunate issue still is that if the instancing object is used
for something else, we might be running into a threading conflict.
Possible solution would be to create a temp copy of an object, but
then it will be an issue of preventing drivers from modifying other
datablocks.
At least the original issue is fixed now, and things behave same as
in older Blender version. Additionally, the global variable which
was defining curve speed flag behavior is gone now!
This aims to resolve a conflict where some users want to keep keyboard
axis setting global, even when the orientation is set to something else.
Move/rotate/scale can optionally each have a separate orientation.
Some UI changes will be made next.
Display statistics from CCG structure.
This makes values to be different from what is shown in object
mode, since CCG is operating on individual grids, and object
mode will stitch those grids. But on another, those values from
CCG is what sculpt mode is actually "sees" or "uses".
The number of faces should be the same in both sculpt and object
modes.
This resolves this issue where users would enable a snapping mode
besides incremental (vertex for eg), then notice strange behavior w/
rotate and scale.
While this ability can be useful, it's quite an obscure use case.
Now changing snap-modes keeps rotate and scale using incremental snap,
with the option for these modes to be affected by other snapping modes.
D4022 by @kioku w/ own minor edits.
This is a second attempt to get the crash fixed. The original fix
worked, but it was reverted by d3e0d7f082.
Now the logic goes as:
- All pointers which we can not have shared (the ones which are
owned by the runtime) are cleared.
- The rest of runtime stays untouched.
This seems to be enough to keep particles happy.
This commit adds support for new curve tool and adds more functionalities to the existing primitives, including new handles, editing, stroke thickness curve, noise, preview of the real stroke, etc.
Thanks to @charlie for his great contribution to this improvement.
NLA strips support using the keyframe values in a variety of ways:
adding, subtracting, multiplying, linearly mixing with the result
of strips located below in the stack. This is intended for layering
tweaks on top of a base animation.
However, when inserting keyframes into such strips, it simply inserts
the final value of the property, irrespective of these settings. This
in fact makes the feature nearly useless.
To fix this it is necessary to evaluate the NLA stack below the
edited strip and correctly compute the raw key that would produce
the intended final value, according to the mode and influence.
Differential Revision: https://developer.blender.org/D3927
The issue was caused by a special code in node tree freeing function
which will free extra fields in the case when tree is not in bmain.
This is how old code was dealing with "nested" trees, but is now
making behavior different from other datablocks. This is exactly
what was confusing copy-on-write logic.
Ideally, ntreeFreeTree() need to behave same as all other datablocks,
ad freeing of data of nested trees should be up to the owner of the
tree (this way it's all explicit and does not depend on check of
some special flag.
This restores the object->data to a non-modifier evaluated state.
So this allow us to change evaluated object modifier stack directly and
get BKE_mesh_new_from_object() for the evalauted object.
