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
For 2.90 release this should not be exposed in the RNA API.
In master this needs to be ON by default, that's all.
Differential Revision: https://developer.blender.org/D8589
The Pass struct is now a Node and the passes are moved from the Film
class to the Scene class.
The Pass Node only has `type` and `name` as sockets as those seem to be
the only properties settable by exporters (other properties are implicit
and depend on the pass type).
This is part of T79131.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8591
This moves `Session::get_requested_device_features`,
`Session::load_kernels`, and `Session::update_scene` out of `Session`
and into `Scene`, as mentioned in D8544.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8590
The previous algorithm was not using all of the requested grids to build a mesh
around the volume due to limitations regarding the use of a dense buffer to
gather information about the volume's topology. This resulted in artefacts during
rendering.
The mesh generation is now done by merging all of the input grids and using the
resulting grid's topology to create the mesh. The generation of the mesh
is still done in index space as before, and the vertices are converted to object
space by using the merged topology grid indexToWorld transform.
To be able to merge the grids together we have to make sure that their transformation
matrices and their index spaces match, thus, if they do not match we simply resample
the grids. This behaviour should tackle one other limitation of the current algorithm,
which is that only one transformation matrix was used to generate the final mesh.
If we do not have an OpenVDB grid for the requested volume data, we generate
a temporary OpenVDB grid for it.
Differential Revision: https://developer.blender.org/D8401
This reverts commit 88cc3f167f7ee404640289ed9cfd6b13f0494d98. It was
caused by running Clang-Format version 10, instead of 9 from the
precompiled libs directory.
In an upcoming bugfix we'll use OpenVDB data structures directly to build mesh
for sparse OpenVDB volumes, loading them OpenVDB grids earlier and removing any
references to Blender data structures makes that easier.
This also makes changes to Blender volumes to support this, so Cycles can take
ownership of a grid without Blender having to keep its own reference to it.
This should also be useful in a future Python API.
Ref D8401
Optimization was disabled in this function to work around a bug in MSVC, use
a different solution that does not come with such a big performance regression.
The decomposed transform would have consists of nan values if the input
transform had zero scale.
Now the decomposition will check for zero scale, and if it is detected
then the result will be ensured to be finite. Additionally, rotation
value will be copied from previous/next time step to help avoiding
obscure interpolation.
The latter step can become more comprehensive than the current simple
implementation.
Differential Revision: https://developer.blender.org/D8450
This patch adds the ability to render motion blur from Alembic caches.
The motion blur data is derived from a velocity attribute whose name has
to be defined by the user through the MeshSequenceCache modifier, with a
default value of ".velocities", which is the standard name in Alembic
for the velocity property, although other software may ignore it and
write velocity with their own naming convention (e.g. "v" in Houdini).
Furthermore, a property was added to define how the velocity vectors
are interpreted with regard to time : frame or second. "Frame"
means that the velocity is already scaled by the time step and we do not
need to modify it for it to look proper. "Second" means that the unit
the velocity was measured in is in seconds and so has to be scaled by
some time step computed here as being the time between two frames (1 /
FPS, which would be typical for a simulation). This appears to be
common, and is the default behavior.
Another property was added to control the scale of the velocity to
further modify the look of the motion blur.
Reviewed By: brecht, sybren
Differential Revision: https://developer.blender.org/D2388
Caused by c7aa0f9d743ee9cafe91b4a51d9f1ecc5e437d71.
Since above commit, BKE_image_user_frame_calc requires an image (not
just the iuser) to get the framenumber.
Cycles used to call this with NULL image (in `image_user_file_path` and
`image_user_frame_number`), now pass the image as well.
Maniphest Tasks: T79111
Differential Revision: https://developer.blender.org/D8439
The fisheye camera setup causes the edges of the image to not shoot primary rays. This was not
respected by OptiX because of an optimization that tried to reduce conditionals around trace calls.
Removing that does not seem to have an impact on performance anymore however and it fixes
the issue.
The OptiX kernels are compiled for target "compute_sm_52", which is only available on second
generation Maxwell GPUs, so disable support for older ones.
The sky will appear brighter than before by default. To compensate for this,
lower exposure in the Film panel. The default altitude was also changed from
90 to 15 degrees.
Patch contributed by Marco with the help of Ryan Jones.
Differential Revision: https://developer.blender.org/D8285
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
