Age | Commit message (Collapse) | Author |
|
This commit adds a node that generates a text paragraph as curve
instances. The inputs on the node control the overall shape of the
paragraph, and other nodes can be used to move the individual instances
afterwards. To output more than one line, the "Special Characters" node
can be used.
The node outputs instances instead of real geometry so that it doesn't
have to duplicate work for every character afterwards. This is much
more efficient, because all of the curve evaluation and nodes like fill
curve don't have to repeat the same calculation for every instance of
the same character.
In the future, the instances component will support attributes, and the
node can output attribute fields like "Word Index" and "Line Index".
Differential Revision: https://developer.blender.org/D11522
|
|
With this commit, curve objects support the geometry nodes modifier.
Curves objects now evaluate to `CurveEval` unless there was a previous
implicit conversion (tessellating modifiers, mesh modifiers, or the
settings in the curve "Geometry" panel). In the new code, curves are
only considered to be the wire edges-- any generated surface is a mesh
instead, stored in the evaluated geometry set.
The consolidation of concepts mentioned above allows remove a lot of
code that had to do with maintaining the `DispList` type temporarily
for modifiers and rendering. Instead, render engines see a separate
object for the mesh from the mesh geometry component, and when the
curve object evaluates to a curve, the `CurveEval` is always used for
drawing wire edges.
However, currently the `DispList` type is still maintained and used as
an intermediate step in implicit mesh conversion. In the future, more
uses of it could be changed to use `CurveEval` and `Mesh` instead.
This is mostly not changed behavior, it is just a formalization of
existing logic after recent fixes for 2.8 versions last year and two
years ago. Also, in the future more functionality can be converted
to nodes, removing cases of implicit conversions. For more discussion
on that topic, see T89676.
The `use_fill_deform` option is removed. It has not worked properly
since 2.62, and the choice for filling a curve before or after
deformation will work much better and be clearer with a node system.
Applying the geometry nodes modifier to generate a curve is not
implemented with this commit, so applying the modifier won't work
at all. This is a separate technical challenge, and should be solved
in a separate step.
Differential Revision: https://developer.blender.org/D11597
|
|
Evaluating the dependency graph potentially executes Python code when
evaluating drivers. In specific situations (see T91046) this could
deadlock Blender entirely. Temporarily releasing the GIL when evaluating
the depsgraph resolves this.
This is an improved version of
rBfc460351170478e712740ae1917a2e24803eba3b, thanks @brecht for the diff!
Manifest task: T91046
|
|
It is causing crashes in rendering, when releasing the GIL in render threads
while the main thread is holding it.
Ref T91046
This reverts commit fc460351170478e712740ae1917a2e24803eba3b.
|
|
Evaluating the dependency graph potentially executes Python code when
evaluating drivers. In specific situations (see T91046) this could deadlock
Blender entirely. Temporarily releasing the GIL when evaluating the depsgraph
resolves this.
Calling the `BPy_BEGIN_ALLOW_THREADS` macro is relatively safe, as it's
a no-op when the current thread does not have the GIL.
Developed in collaboration with @sergey
Manifest task: T91046
|
|
Previously, the Point Instance node in geometry nodes could only instance
existing objects or collections. The reason was that large parts of Blender
worked under the assumption that objects are the main unit of instancing.
Now we also want to instance geometry within an object, so a slightly larger
refactor was necessary.
This should not affect files that do not use the new kind of instances.
The main change is a redefinition of what "instanced data" is. Now, an
instances is a cow-object + object-data (the geometry). This can be nicely
seen in `struct DupliObject`. This allows the same object to generate
multiple geometries of different types which can be instanced individually.
A nice side effect of this refactor is that having multiple geometry components
is not a special case in the depsgraph object iterator anymore, because those
components are integrated with the `DupliObject` system.
Unfortunately, different systems that work with instances in Blender (e.g.
render engines and exporters) often work under the assumption that objects are
the main unit of instancing. So those have to be updated as well to be able to
handle the new instances. This patch updates Cycles, EEVEE and other viewport
engines. Exporters have not been updated yet. Some minimal (not master-ready)
changes to update the obj and alembic exporters can be found in P2336 and P2335.
Different file formats may want to handle these new instances in different ways.
For users, the only thing that changed is that the Point Instance node now
has a geometry mode.
This also fixes T88454.
Differential Revision: https://developer.blender.org/D11841
|
|
Clearing the Parent Bone field in relations would result in something
like this:
```
add_relation(Bone Parent) - Could not find op_from
(ComponentKey(OBArmature, BONE))
add_relation(Bone Parent) - Failed, but op_to (ComponentKey(OBEmpty,
TRANSFORM)) was ok
ERROR (bke.object): /source/blender/blenkernel/intern\object.c:3330
ob_parbone: Object Empty with Bone parent: bone doesn't exist
```
Now skip creation of a depsgraph relation if the Parent Bone field is
empty (since this would be invalid anyways).
ref. T91101
Maniphest Tasks: T91101
Differential Revision: https://developer.blender.org/D12389
|
|
When the same stroke was used as a driver variable, this could make this
stroke already tagged as built in the course of building driver
variables (via `build_gpencil`), but then important stuff from
`build_object_data_geometry_datablock` could be missed later on (because
both of these funtions use `checkIsBuiltAndTag`). Most importantly,
setting up operations such as GEOMETRY_EVAL would be skipped entirely.
`build_object_data_geometry_datablock` seems to cover greasepencil just
fine (does the same as `build_gpencil` and more). Proposed solution is to
remove `build_gpencil` entirely. In `build_id` it would then also call
`build_object_data_geometry_datablock` for `ID_GD` IDs. Now the covered
types that _call_ `build_object_data_geometry_datablock` match exactly
to what is covered _inside_ `build_object_data_geometry_datablock`.
Think this "duplication" of functionality was just overseen in
rB66da2f537ae8 [`build_gpencil` existed long before and said commit made
greasepencil a real object with geometry and such].
thx @JacquesLucke for additional input!
Maniphest Tasks: T88433
Differential Revision: https://developer.blender.org/D12324
|
|
|
|
We now use a for_each function with callback to iterate through all sequences in the scene.
This has the benefit that we now only loop over the sequences in the scene once.
Before we would loop over them twice and allocate memory to store temporary data.
The allocation of temporary data lead to unintentional memory leaks if the code used returns to exit out of the iteration loop.
The new for_each callback method doesn't allocate any temporary data and only iterates though all sequences once.
Reviewed By: Richard Antalik, Bastien Montagne
Differential Revision: http://developer.blender.org/D12278
|
|
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
|
|
|
|
- Only do print when asked for tags debugging.
- Add missing newline to the message.
|
|
This caused Cycles texture_space_mesh_modifier and panorama_dicing tests to
randomly fail.
The issue was introduced with D11377, due to a missing dependency. Now ensure
we first copy the texture space parameters, and only then use or recompute then.
In general it seems like this dependency should have already been there, since
parameter evaluation includes animation and drivers, and geometry evaluation
may depend on that (even if you would not typically animate e.g. an autosmooth
angle).
Thanks Campbell for tracking this one down.
|
|
|
|
|
|
This makes the internal naming consistent with the public API. And also gives
us a visibility_flag rather than restrictflag that can be extended with more
flags.
|
|
|
|
|
|
|
|
Use C comments for plain text.
|
|
This reverts commits
bfa3dc91b75407b063f2ac991b176d98c050f92d,
52b94049f2a71a74f52247f83657cf3a5c8712b4,
ae379714e4f1eca74f5f77532a6e959f29445236,
a770faa811ee62837eb540b0bd83ca0770f16663,
4ed029fc02b022cb5ff28ed3ce70992c450d2be5,
101a493ab556c6597ac91fba204059be67b35990 and
62a2faa7ef39130446716d7a06215cd1df1eb2ac.
And fixes T89955.
Changing the dependency graph is a can of worms and the result is
a kind of unpredictable.
A different solution will be planned.
|
|
Update was skipping the batch cache.
|
|
Regression introduced in {rBbfa3dc91b754}.
`ID_RECALC_GEOMETRY` should tag all operations of the `GEOMETRY`
component and not just the operation of node `GEOMETRY_EVAL_INIT`.
|
|
`POINT_CACHE_RESET` pointed to `GEOMETRY_EVAL_INIT` while
`GEOMETRY_EVAL_INIT` pointed to `POINT_CACHE_RESET`.
Now `POINT_CACHE_RESET` points to the same nodes pointed to by
`GEOMETRY_EVAL_INIT` thus avoiding the dependency cycle.
|
|
|
|
This shows the text as part of the assertion message.
|
|
Differential Revision: https://developer.blender.org/D11851
|
|
During a mesh transformation in edit mode (Move, Rotate...), only part of
the batch cache needs to be updated.
This commit allows only update only the drawn batches seen in
`BKE_object_data_eval_batch_cache_deform_tag` if the new
`ID_RECALC_GEOMETRY_DEFORM` flag is used.
This new flag is used in the transforms operation for edit-mesh and
results in 1.6x overall speedup in heavy subdiv cube.
Differential Revision: https://developer.blender.org/D11599
|
|
In this bug report it resulted in rendering animations stopping too early,
but this affected more areas.
After the previous cleanup commit, it becomes clear that frame and ctime
values were mixed up.
|
|
Confusingly, BKE_scene_frame_get did not match the frame number as expected by
BKE_scene_frame_set. Instead it return the value after time remapping, which
is commonly named "ctime".
* Rename BKE_scene_frame_get to BKE_scene_ctime_get
* Add a new BKE_scene_frame_get that matches BKE_scene_frame_set
* Use int/float depending if fractional frame is expected
|
|
The geometry nodes modifier uses id properties for the inputs to node groups.
That is because the set of properties changes depending on which geometry
node group is selected.
The animation was not updated correctly because the `ANIMATION_EVAL`
depsgraph node was not evaluated, because nothing depended on it in the
depsgraph. This patch makes sure that the proper link to the geometry
component is inserted.
Differential Revision: https://developer.blender.org/D11831
|
|
|
|
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
This worked for existing scenes but adding new objects was asserting
needs further investigation.
|
|
This resolves a bottleneck where every update while transforming
copied the entire mesh data-block, which isn't needed as the edit-mesh
is the source of the data being edited.
Testing shows a significant overall speedup when transforming:
- ~1.5x with a subdivided cube 1.5 million vertices.
- ~3.0x with the spring mesh (edit-mode with modifiers disabled,
duplicated 10x to drop performance).
Reviewed By: sergey
Ref D11337
|
|
Avoid computationally expensive copying operations
when only some settings have been modified.
This is done by adding support for updating parameters
without tagging for copy-on-write.
Currently only mesh data blocks are supported,
other data-blocks can be added individually.
This prepares for changing values such as edit-mesh auto-smooth angle
in edit-mode without duplicating all mesh-data.
The benefit will only be seen when the user interface no longer tags
all ID's for copy on write updates.
ID_RECALC_GEOMETRY_ALL_MODES has been added to support situations
where non edit-mode geometry is modified in edit-mode.
While this isn't something user are likely to do,
Python scripts may change the underlying mesh.
Reviewed By: sergey
Ref D11377
|
|
Without this tests fail to lknk in D11377. Commit separately as the
depsgraph is using BKE it should link to it.
|
|
|
|
Would crash when adding or removing a collection directly to the master
collection of a scene.
Consequence of change to handle depsgraph-controlled evaluation of some
IDs (like excluded collections which do not get evaluated and do not get
a COW anymore). See rBcf4258673755 and D10907.
Note that this mostly demonstrates once again how weak and flacky our
handling of embedded IDs still remains, with some part of the code
handling them as independent IDs, some as fully local/private data, some
as a mix of both... and lots and lots of custom handling code and corner
cases that are a bottomless pit of issues.
Also quiet incredible that this was not reported already, luckily this
original change did not make it to 2.93 release.
|
|
Delay depsgraph visibility update tagging until it is known that
graph relations are up to date, and until it is known that the graph
is actually needed to be evaluated.
Differential Revision: https://developer.blender.org/D11660
|
|
No functional changes. Just makes it clear this is not an immediate
update, and will make an upcoming change more localized.
|
|
In addition to the base bone transformation itself, B-Bones have
controls that affect transformation of its segments. For rotation
the features are quite complete, allowing to both reorient the
Bezier handles via properties, and to control them using custom
handle bones. However for scaling there are two deficiencies.
First, there are only X and Y scale factors (actually X and Z),
while lengthwise all segments have the same scaling. The ease
option merely affects the shape of the curve, and does not cause
actual scaling.
Second, scaling can only be controlled via properties, thus
requiring up to 6 drivers per joint between B-Bones to transfer
scaling factors from the handle bone. This is very inefficient.
Finally, the Z channels are confusingly called Y.
This commit adds a B-Bone Y Scale channel and extra B-Bone flag
fields to DNA with appropriate versioning (including for F-Curves
and drivers) in preparation to addressing these limitations.
Functionality is not changed, so the new fields are not used
until the following commits.
Differential Revision: https://developer.blender.org/D9870
|
|
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
|
|
These were limited to obvious cases. Some less obvious cases
were kept as refactoring might make them necessary in future.
|
|
|
|
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.
Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.
This fixes T88598.
Differential Revision: https://developer.blender.org/D11415
|
|
This patch adds relatively small changes to the curve draw
cache implementation in order to draw the curve data in the
viewport. The dependency graph iterator is also modified
so that it iterates over the curve geometry component, which
is presented to users as `Curve` data with a pointer to the
`CurveEval`
The idea with the spline data type in geometry nodes is that
curve data itself is only the control points, and any evaluated
data with faces is a mesh. That is mostly expected elsewhere in
Blender anyway. This means it's only necessary to implement
wire edge drawing of `CurveEval` data.
Adding a `CurveEval` pointer to `Curve` is in line with changes
I'd like to make in the future like using `CurveEval` in more places
such as edit mode.
An alternate solution involves converting the curve wire data
to a mesh, however, that requires copying all of the data, and
since avoiding it is rather simple and is in-line with future plans
anyway, I think doing it this way is better.
Differential Revision: https://developer.blender.org/D11351
|