| Age | Commit message (Collapse) | Author |
|---|
|
Part of the fix is by Jacques. This fixes the most obvious case, but it's
still not clear how to deal with non-mesh geometry instances or how to handle
motion blur for such instances.
|
|
|
|
Previously fluid simulation and Alembic modifiers had a dedicated function
to query the velocity for motion blur. Now use a more generic system where
those modifiers output a velocity attribute.
Advantages:
* Geometry and particle nodes can output velocity through the same mechanism,
or read the attribute coming from earlier modifiers.
* The velocity can be preserved through modifiers like subdivision surface or
auto smooth.
* USD and Alembic previously only output velocity from fluid simulation, now
they work with velocity from other sources too.
* Simplifies the code for renderers like Cycles and exporters like
Alembic and USD.
This breaks compatibility:
* External renderers and exporters accessing these velocities through the
Python API now need to use the attribute instead.
* Existing modifier node setups that create an attribute named "velocity"
will render differently with motion blur.
Differential Revision: https://developer.blender.org/D12305
|
|
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
|
|
Using rna iterators in range-based for loops is possible since {rBc4286ddb095d32714c9d5f10751a14f5871b3844}.
This patch only updates the places that are easy to update
without more changes in surrounding code.
Differential Revision: https://developer.blender.org/D10195
|
|
Ref D3089
|
|
This optimizes device updates (during user edits or frame changes in
the viewport) by avoiding unnecessary computations. To achieve this,
we use a combination of the sockets' update flags as well as some new
flags passed to the various managers when tagging for an update to tell
exactly what the tagging is for (e.g. shader was modified, object was
removed, etc.).
Besides avoiding recomputations, we also avoid resending to the devices
unmodified data arrays, thus reducing bandwidth usage. For OptiX and
Embree, BVH packing was also multithreaded.
The performance improvements may vary depending on the used device (CPU
or GPU), and the content of the scene. Simple scenes (e.g. with no adaptive
subdivision or volumes) rendered using OptiX will benefit from this work
the most.
On average, for a variety of animated scenes, this gives a 3x speedup.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D9555
|
|
This encapsulates Node socket members behind a set of specific methods;
as such it is no longer possible to directly access Node class members
from exporters and parts of Cycles.
The methods are defined via the NODE_SOCKET_API macros in `graph/
node.h`, and are for getting or setting a specific socket's value, as
well as querying or modifying the state of its update flag.
The setters will check whether the value has changed and tag the socket
as modified appropriately. This will let us know how a Node has changed
and what to update, which is the first concrete step toward a more
granular scene update system.
Since the setters will tag the Node sockets as modified when passed
different data, this patch also removes the various modified methods
on Nodes in favor of Node::is_modified which checks the sockets'
update flags status.
Reviewed By: brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D8544
|
|
Uniform attributes require immediate access to the shader list
in object update code, so setting the field can't be deferred
to a background task. This required adding a parameter to the
clear method of Geometry.
Ref D2057
|
|
This reverts commit 527f8b32b32187f754e5b176db6377736f9cb8ff. It is causing
motion blur test failures and crashes in some renders, reverting until this is
fixed.
|
|
This encapsulates Node socket members behind a set of specific methods;
as such it is no longer possible to directly access Node class members
from exporters and parts of Cycles.
The methods are defined via the NODE_SOCKET_API macros in `graph/
node.h`, and are for getting or setting a specific socket's value, as
well as querying or modifying the state of its update flag.
The setters will check whether the value has changed and tag the socket
as modified appropriately. This will let us know how a Node has changed
and what to update, which is the first concrete step toward a more
granular scene update system.
Since the setters will tag the Node sockets as modified when passed
different data, this patch also removes the various `modified` methods
on Nodes in favor of `Node::is_modified` which checks the sockets'
update flags status.
Reviewed By: brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D8544
|
|
|
|
Now that volume is a dedicated geometry type in Cycles, we need to re-allocate
the geometry when a mesh changes into a volume.
|
|
This improves performance in scene synchronization when there are many
mesh, hair and volume objects. Sync time speedups in benchmarks:
barbershop 5.2x
bmw 1.3x
fishycat 1.5x
koro 1.0x
sponza 3.0x
victor 1.4x
wdas_cloud 0.9x
Implementation by Nicolas Lelong, and Jagannadhan Ravi (AMD).
Differential Revision: https://developer.blender.org/D9258
|
|
Problem: the Blender synchronization process creates and tags nodes for usage. It does
this by directly adding and removing nodes from the scene data. If some node is not tagged
as used at the end of a synchronization, it then deletes the node from the scene. This poses
a problem when it comes to supporting procedural nodes who can create other nodes not known
by the Blender synchonization system, which will remove them.
Nodes now have a NodeOwner, which is set after creation. Those owners for now are the Scene
for scene level nodes and ShaderGraph for shader nodes. Instead of creating and deleting
nodes using `new` and `delete` explicitely, we now use `create_node` and `delete_node` methods
found on the owners. `delete_node` will assert that the owner is the right one.
Whenever a scene level node is created or deleted, the appropriate node manager is tagged for
an update, freeing this responsability from BlenderSync or other software exporters.
Concerning BlenderSync, the `id_maps` do not explicitely manipulate scene data anymore, they
only keep track of which nodes are used, employing the scene to create and delete them. To
achieve this, the ParticleSystem is now a Node, although it does not have any sockets.
This is part of T79131.
Reviewed By: #cycles, brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8540
|
|
This splits the volume related data (properties for rendering and attributes) of the Mesh node
into a new `Volume` node type.
This `Volume` node derives from the `Mesh` class since we generate a mesh for the bounds of the
volume, as such we can safely work on `Volumes` as if they were `Meshes`, e.g. for BVH creation.
However such code should still check for the geometry type of the object to be `MESH` or `VOLUME`
which may be bug prone if this is forgotten.
This is part of T79131.
Reviewed By: brecht
Maniphest Tasks: T79131
Differential Revision: https://developer.blender.org/D8538
|
|
This replaces the cmake options `WITH_NEW_OBJECT_TYPES` and
`WITH_NEW_SIMULATION_TYPE` with two experimental userpref settings:
* `use_new_particle_system`: Enables the point cloud type and the simulation editor.
* `use_new_hair_type`: Only displays the add-operator in the add menu for now.
Note, in the current state you can't do anything productive with the new particle
system or the new hair type. Features will be added step by step in the upcoming
weeks and months.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8096
|
|
Triangles were very memory intensive. The only reason they were not removed yet
is that they gave more accurate results, but there will be an accurate 3D curve
primitive added for this.
Line rendering was always poor quality since the ends do not match up. To keep CPU
and GPU compatibility we just remove them entirely. They could be brought back if
an Embree compatible implementation is added, but it's not clear to me that there
is a use case for these that we'd consider important.
Ref T73778
Reviewers: #cycles
Subscribers:
|
|
Ref T68981
|
|
Voxels are loaded directly from the OpenVDB grid. Rendering still only supports
dense grid, so memory usage is not great for sparse volumes, this is to be
addressed in the future.
Ref T73201
|
|
|
|
|
|
|
|
|
