| Age | Commit message (Collapse) | Author |
|---|
|
|
|
These seem to be causing some stability issues, and really are just not that
useful in practice. Compiling them is slow already, so it does not improve
the user experience much to show an AO preview if it's not nearly instant.
|
|
|
|
|
|
lookups
We use the schema so that we can access top level attributes as well.
This is already done for polygon meshes and curves, so this only
modifies the behavior for subdivision objects.
|
|
Although it is not a pointer, accessing an ICompoundProperty
dereferences a pointer under the hood, so check for validity.
|
|
|
|
|
|
|
|
This issue originates from a missing BVH packing for visibility data
when it is modified.
To fix this, this adds update flags to the managers to carry the
modified visibility information from the Objects' modified flag to the
GeometryManager.
Another set of flags is added to determine which data need to be packed:
geometry, vertices, or visibility. Those flags are then used when
packing the primivites.
Reviewed By: brecht
Maniphest Tasks: T87929
Differential Revision: https://developer.blender.org/D11219
|
|
LLVM Clang 13, macOS.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D11207
|
|
|
|
The render session is keeping track of the scene update, which includes
kernel loading time.
This fixes negative render times reported when CUDA kernels are compiled
at runtime.
A bit fragile logic, can be re-implemented using some user-counted
scope utility classes, so that only outer-most time skip is applied.
|
|
Thanks to @Severin for noticing and providing a little patch.
|
|
|
|
|
|
|
|
This precomputes vertex normals in the procedural and caches them in case none
are found in the archive. This only applies to polygon meshes, as subdivision
meshes are yet to be subdivided, so it is useless to do this computation.
The goal here is to speed up data updates between frames, as computing normals
shows up in profiles even for large objects. This saves around 16% of update time
for a production file.
|
|
This splits the data reading logic from the AlembicObject class and moves it to
separate files to better enforce a separation of concern. The goal was to simplify
and improve the logic to read data from an Alembic archive.
Since the procedural loads data for the entire animation, this requires looping
over the frame range and looking up data for each frame. Previously those loops
would be duplicated over the entire code causing divergences in how we might
skip or deduplicate data across frames (if only some data change over time and
not other on the same object, e.g. vertices and triangles might not have the
same animation times), and therefore, bugs.
Now, we only use a single function with callback to loop over the geometry data
for each requested frame, and another one to loop over attributes. Given how
attributes are accessed it is a bit tricky to simplify further and only use a
ingle function, however, this is left as a further improvement as it is not
impossible.
To read the data, we now use a set of structures to hold which data to read.
Those structures might seem redundant with the Alembic schemas as they are
somewhat a copy of the schemas' structures, however they will allow us in the
long run to treat the data of one object type as the data of another object
type (e.g. to ignore subdivision, or only loading the vertices as point clouds).
For attributes, this new system allows us to read arbitrary attributes, although
with some limitations still:
* only subdivision and polygon meshes are supported due to lack of examples for
curve data;
* some data types might be missing: we support float, float2, float3, booleans,
normals, uvs, rgb, and rbga at the moment, other types can be trivially added
* some attribute scopes (or domains) are not handled, again, due to lack of example
files
* color types are always interpreted as vertex colors
|
|
Shaders are only compiled if they are used by some other Node (Geometry, Light, etc.).
This usage detection is done before updating the Scene, however it fails at detecting
Shaders used by Procedurals not known to Cycles (e.g. ones defined by third party
applications), as Procedurals are only updated after the shaders are compiled.
To remedy this, we now use the Node reference counting mechanism to detect whether a
Shader is used and therefore should be compiled.
This removes `ShaderManager::update_shaders_used` as it is not needed anymore, however,
since it would also update the Shader ids, this is now performed in
`ShaderManager::device_update`, and a new virtual `device_update_specific` method was
added to handle device updates for SVM and OSL.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D10965
|
|
This adds a reference count to Nodes which is incremented or decremented
whenever they are added to or removed from a socket, which will help us
track used Nodes throughout the scene graph generically without having to
add an explicit count or flag on specific Node types. This is especially
useful to track Nodes defined through Procedurals out of Cycles' control.
This also modifies the order in which nodes are deleted to ensure that
upon deletion, a Node does not attempt to decrement the reference
count of another Node which was already freed or deleted.
This is not currently used, but will be in the next commit.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D10965
|
|
|
|
|
|
|
|
For indirect light rays, don't assume any hit is opaque, rather if it has
transparency or emission do the shading but don't do any further bounces.
Naturally this is slower when there are transparent surfaces, however
without this cutout opacity doesn't give sensible results.
Differential Revision: https://developer.blender.org/D10985
|
|
|
|
|
|
For Cycles, when enabling the Persistent Data option, the full render data
will be preserved from frame-to-frame in animation renders and between
re-renders of the scene. This means that any modifier evaluation, BVH
building, OpenGL vertex buffer uploads, etc, can be done only once for
unchanged objects. This comes at an increased memory cost.
Previously there option was named Persistent Images and had a more limited
impact on render time and memory.
When using multiple view layers, only data from a single view layer is
preserved to keep memory usage somewhat under control. However objects
shared between view layers are preserved, and so this can speedup such
renders as well, even single frame renders.
For Eevee and Workbench this option is not available, however these engines
will now always reuse the depsgraph for animation and multiple view layers.
This can significantly speed up rendering.
These engines do not support sharing the depsgraph between re-renders, due
to technical issues regarding OpenGL contexts. Support for this could be added
if those are solved, see the code comments for details.
|
|
|
|
This simulates the effect of a honeycomb or grid placed in front of a softbox.
In practice, it works by attenuating rays coming off-angle as a function of the
provided spread angle parameter.
Setting the parameter to 180 degrees poses no restrictions to the rays, making
the light behave the same way as before this patch.
The total light power is normalized based on the spread angle, so that the
light strength remains the same.
Differential Revision: https://developer.blender.org/D10594
|
|
|
|
|
|
This should only be accessed from within the procedural.
|
|
or shaders
The index_data_map was not cleared when clearing a cache, so this would just append
the new correct data to the end of the array instead of overwriting it, which would
cause us to then use outdated indices.
|
|
When the strength is initially set to zero, the shader graph is
optimized out to remove any node which will not be executed because of
this, which removes pretty much every single node, except for the
output. As the graph is empty, the world shader is made invisible to
rays so it is not evaluated in the kernel.
However, when the strength is then modified, the Background is not
updated as the modification happens on the Shader Node and not on the
Background Node, so it is never tagged as modified.
To fix this, we need to tag the Background as modified when its shader
is also modified so the Kernel data is properly updated.
Regression caused by rBbbe6d44928235cd4a5cfbeaf1a1de78ed861bb92.
|
|
It is causing issue with AMD OpenCL drivers, due to a potential driver bug.
Ref T84461
|
|
|
|
As a rather premature optimization from rBbbe6d4492823, Object bounds
were only computed when either the Object or its Geometry were modified.
Prior to rB42198e9eb03b, this would work, as the Geometry was tagged as
modified if the Object's transform was also modified.
Since this tagging is not done anymore due to side effects, and since at
the time bounds are computed Objects were already processed and tag as
unmodified, the check on the modified status was always false.
For now remove this check, so the bounds are always unconditionally
updated. If this ever becomes a performance problem in large scenes with
motion blur, we will then try to find a way to nicely optimize it.
This would only affect BHV2 as OptiX and Embree handle object bounds
themselves.
|
|
Currently the procedural will add an entry to the cache for every frame
even if the data only changes seldomly. This means that in some cases we
will have duplicate data accross frames.
The cached data is now stored separately from the time information, and
an index is used to retrieve it based on time. This decoupling allows
for multiple frames to point to the same data.
To check if two arrays are the same, we compute their keys using the
Alembic library's routines (which is based on murmur3), and tell the
cache to reuse the last data if the keys match.
This can drastically reduce memory usage at the cost of more processing
time, although processing time is only increased if the topology may
change.
|
|
|
|
In order to update the BVH when only the transformations are changing,
we would tag the Object's Geometry as modified. However, when
displacement is used, and the vertices were not themselves modified,
this would cause us to redo the displacement on already displaced
vertices.
To fix this, use a specific update flag for detecting and notifying that
transformations were modified.
Regression caused by rBbbe6d44928235cd4a5cfbeaf1a1de78ed861bb92.
|
|
The crash is caused by an out of bound access in the kernel due to
missing data update when a Volume's voxel data changes. Although the
previous bounding mesh is cleared, the Volume Node was not tagged as
modified, and therefore never rebuilt.
To fix this, tag the Geometries (not just Volumes, to be more robust) as
modified in Geometry.clear().
Regression caused by rBbbe6d44928235cd4a5cfbeaf1a1de78ed861bb92.
|
|
Cycles, Eevee, OSL, Geo, Attribute
Based on outdated refract patch D6619 by @cubic_sloth
`refract` and `faceforward` are standard functions in GLSL, OSL and Godot shader languages.
Adding these functions provides Blender shader artists access to these standard functions.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D10622
|
|
|
|
|
|
Static initialization order was not guaranteed to be correct for node base
types. Now wrap all initialization in accessor functions to ensure the order
is correct.
Did not cause any known bug on Linux/macOS/Windows, but showed up on this
platform.
|
|
|
|
This type, CacheLookupResult, holds the data for the current time, or an
explanation as to why no data is available (already loaded, or simply
nothing available). This is useful to document the behavior of the code
but also, in future changes, to respond appropriately for missing data.
|
|
Inside of the procedural, instances are AlembicObjects which point to
the AlembicObject that they instance.
In Alembic, an instance is an untyped Object pointing to the original
(instanced) one through its source path. During the archive traversal we
detect such instances and, only if the instanced object is asked to be
rendered, set the instance's AlembicObject to point to the original's
AlembicObject.
Cycles Object Nodes are created for each AlembicObject, but only for
non-instances are Geometries created, which are then shared between
Object Nodes. It is supposed, and expected, that all instances share the
same shaders, which will be set to be the ones found on the original
object.
As for caching, the data cache for an AlembicObject is only valid for
non-instances and should not be read to or from as it is implicitly
shared.
|
|
This will help support instancing as cache building is now decoupled
from the logic to update the Nodes' sockets as data (and cache) will
need to be shared by different Geometries somehow, and also simplify
implementing different data caching methods by centralizing this
operation.
|
