Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
NanoVDB is a platform-independent sparse volume data structure that makes it possible to
use OpenVDB volumes on the GPU. This patch uses it for volume rendering in Cycles,
replacing the previous usage of dense 3D textures.
Since it has a big impact on memory usage and performance and changes the OpenVDB
branch used for the rest of Blender as well, this is not enabled by default yet, which will
happen only after 2.82 was branched off. To enable it, build both dependencies and Blender
itself with the "WITH_NANOVDB" CMake option.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8794
Gathers information for time spent in the various managers or object (Film, Camera, etc.) being updated in Scene::device_update.
The stats include the total time spent in the device_update methods as well as time spent in subroutines (e.g. bvh build, displacement, etc.).
This does not qualify as a full blown profiler, but is useful to identify potential bottleneck areas.
The stats can be enabled and printed by passing `--cycles-print-stats` on the command line to Cycles, or `-- --cycles-print-stats` to Blender.
Reviewed By: brecht
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D8596
* Support precompiled libraries on Linux
* Add license headers
* Refactoring to deduplicate code
Includes work by Ray Molenkamp and Grische for precompiled libraries.
Ref D8769
Before, Cycles was using a shared Embree device across all instances.
This could result in crashes when viewport rendering and material
preview were using Cycles simultaneously.
Fixes issue T80042
Maniphest Tasks: T80042
Differential Revision: https://developer.blender.org/D8772
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
The previous fix loaded the pixels so existing tiles were not overwritten.
However the Cycles render buffer is expected to be scaled by the number of
sample, which was not taken into account.
This is not ideal in that previews could have a mismatched number of samples
between multiple objects, though the result will be correct. The better solution
would be to bake all objects together per tile, rather than one after the other.
But that is a bigger change than we can do in 2.90.
Differential Revision: https://developer.blender.org/D8704
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
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
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
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
For animation/driver purposes, being able to go outside of the 0-360
range makes things easier.
Differential Revision: https://developer.blender.org/D8091
I'm not sure if the Sky was deliberately left out or was just waiting for a
better moment, but so many I was disappointed that Sky in EEVEE is
completely white.
There are already 2 implementations (osl and gpu) so this is the third one.
Looking at other cases it seems that we are not supposed to share sources
between cycles and the rest? So the new util_sky_model files are just
copies of what is already in cycles, except that the data file uses the RGB
variant of the Hosek/Wilkie model, because we output RGB anyway (but can be
easily changed to XYZ if desired - the results are nearly identical).
I am not sure if it is okay to pass 3*9 float values as 3 mat4 uniforms (I
wanted to use mat3 but it does not work).
Also, should I cache the sky model data between renders if the parameters
do not change?
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D7108
Don't apply the matrix transform optimization in this case, curve points and
radius can't represent non-uniform scale the way is possible with triangle
meshes and vertices.
This would cause abrupt change if objects had e.g. motion blur in one frame
and not in the next.
