The issue was that the `object_is_geometry` method was used in two different
contexts that expected the function to behave differently. So a recent change
that fixed `object_is_geometry` for one context, broke it for the other context.
The two contexts are:
* Check if a "real" object can contain a geometry to check if it has to be tagged
for sync after an update.
* Check if an object/instance actually is a geometry that cycles can work with.
I created a new `object_can_have_geometry` method for the first use case, instead
of trying to adapt the existing object_is_geometry method to serve both uses.
Additionally, I changed it so that a BObjectInfo is passed into `object_is_geometry`
to make it more explicit when this method is supposed to be used.
Differential Revision: https://developer.blender.org/D13135
Adds a pass before denoising that calculates the intensity of the image, which can be
passed into the OptiX denoiser for more optimal results for very dark or very bright images.
In addition this also fixes a crash that sometimes occurred on exit. The OptiX denoiser object
has to be destroyed before the OptiX device context object (since it references that). But in
C++ the destructor function of a class is called before its fields are destructed, so
"~OptiXDevice" was always called before "OptiXDevice::~Denoiser" and therefore
"optixDeviceContextDestroy" was called before "optixDenoiserDestroy", hence the crash.
Differential Revision: https://developer.blender.org/D13160
Adds a workaround for a driver bug in r495 that causes artifacts with OptiX denoising.
`optixDenoiserSetup` is not working properly there when called with a stream other than the
default stream, so use the default stream for now and force synchronization across the entire
context afterwards to ensure the other stream Cycles uses to enqueue the actual denoising
command cannot execute before the denoising setup has finished.
Maniphest Tasks: T92472
Differential Revision: https://developer.blender.org/D13158
Changes:
* After hitting a shadow catcher, re-initialize the volume stack taking
into account shadow catcher ray visibility. This ensures that volume objects
are included in the stack only if they are shadow catchers.
* If there is a volume to be shaded in front of the shadow catcher, the split
is now performed in the shade_volume kernel after volume shading is done.
* Previously the background pass behind a shadow catcher was done as part of
the regular path, now it is done as part of the shadow catcher path.
For a shadow catcher path with volumes and visible background, operations are
done in this order now:
* intersect_closest
* shade_volume
* shadow catcher split
* intersect_volume_stack
* shade_background
* shade_surface
The world volume is currently assumed to be CG, that is it does not exist in
the footage. We may consider adding an option to control this, or change the
default. With a volume object this control is already possible.
This includes refactoring to centralize the logic for next kernel scheduling
in intersect_closest.h.
Differential Revision: https://developer.blender.org/D13093
Evaluated meshes from curves are presented to render engines as
separate instance objects now, just like evaluated meshes from other
object types like point clouds and volumes. For that reason, cycles
should not consider curve objects as geometry (previously it did,
meaning it retrieved a second mesh from the curve object as well
as the temporary evaluated mesh geometry).
Further, avoid adding a curve object's evaluated mesh as data_eval,
since that is special behavior for meshes that is arbitrary. Adding an
evaluated mesh there but not an evalauted pointcloud is arbitrary,
for example. Retrieve the evaluated mesh in from the geometry set
in BKE_object_get_evaluated_mesh now, to support that change.
This gets us closer to a place where all of an object's evaluated data
is stored in geometry_set_eval, and we just have helper functions
to access specific geometry components.
Differential Revision: https://developer.blender.org/D13118
The kernel file names are search for based on the arch name, for example
gfx1010. However HIP's gcnArchName can contain options such as xnack- in
the name. For example gfx1010:sramecc-:xnack-.
This revision tokenizes the info from gcnArchName and just uses the first
token for choosing the Kernel file to use. Kernels are portable across those
features in the arch name.
Also remove the bit for recompiling ptx as clearly that is not relevant.
Differential Revision: https://developer.blender.org/D13117
The issue was that some geometries were not synced again even when
they changed. This commit adds a map that keeps track of the geometries
that need to be updated when an object has changed.
Differential Revision: https://developer.blender.org/D13020
We need to store the continuation probability used to make the termination
decision in intersect_closest, instead of recomputing it in shade_surface.
Because otherwise a shade_volume in between can change the throughput and
change the probability.
When reading pixels for virtual passes like diffuse, that sum diffuse direct
and indirect passes, we do not need them to exist with an offset in the render
buffer.
We run into float precision issues here, clamp the number of octaves to
one less, which has little to no visual difference. This was empirically
determined to work up to 16 before, but with additional inputs like
roughness only 15 appears to work.
Also adds misisng clamp for the geometry nodes implementation.
Need to make sure images needed for hair shaders are loaded
before running the shader.
The naming is a bit misleading, but this is an internal API
and we can change it easily. Submitting minimal patch needed
to fix logic in the code to make it safer to review for 3.0.
Differential Revision: https://developer.blender.org/D13067
Instead of printing debug flags listing various CPU and GPU settings that
may or may not be used, print when we are using them. This include CPU
kernel types, OptiX debugging and CUDA and HIP adaptive compilation. BVH
type was already printed.
Looks like OSX changed the default format of its locale, which is not
valid anymore for gettext/boost::locale.
Solution based on investigations and patch by Kieun Mun (@kieuns), with
some further tweaks by Ankit Meel (@ankitm), many thanks.
Also add an exception catcher on `std::runtime_error` in
`bl_locale_set()`, since in OSX catching the ancestor `std::exception`
does not work with `boost::locale::conv::conversion_error` and the like
for some reasons.
Reviewed By: #platform_macos, brecht
Maniphest Tasks: T88877
Differential Revision: https://developer.blender.org/D13019
The current UI for the Scramble Distance patch is grayed out
depending on different settings that are enabled. However it
didn't make much sense to me so I have updated when the UI is
grayed out to hopefully make more sense to the end user.
Differential Revision: https://developer.blender.org/D12963
Adds scrambling distance to the PMJ sampler. This is based
on the work by Mathieu Menuet in D12318 who created the original
implementation for the Sobol sampler.
Reviewed By: brecht
Maniphest Tasks: T92181
Differential Revision: https://developer.blender.org/D12854
saturate is depricated in favour of __saturatef this replaces saturate
with __saturatef on CUDA by createing a saturatef function which replaces
all instances of saturate and are hooked up to the correct function on all
platforms.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13010
Cycles:Distance Scrambling for Cycles Sobol Sampler
This option implements micro jittering an is based on the INRIA
research paper [[ https://hal.inria.fr/hal-01325702/document | on micro jittering ]]
and work by Lukas Stockner for implementing the scrambling distance.
It works by controlling the correlation between pixels by either using
a user supplied value or an adaptive algorithm to limit the maximum
deviation of the sample values between pixels.
This is a follow up of https://developer.blender.org/D12316
The PMJ version can be found here: https://developer.blender.org/D12511
Reviewed By: leesonw
Differential Revision: https://developer.blender.org/D12318
