Render time is reduced for overexposed scenes, by taking into account absolute
light intensity for adaptive sampling.
This can negatively affect some scenes where compositing or color management
are used to make the scene much darker or lighter. For best results adjust the
Film > Exposure setting to bring the intensity into a good range, and then do
further compositing and color management on top of that. Note that this setting
is different than color management exposure.
Previously Cycles' adaptive sampling used sqrt(I) to normalize noise level to
conform to a viewer's eye sensitivity. It is great for darker regions of the
image, but also requests too much samples in bright regions, sometimes several
times more than needed. Highlights can tolerate more noise because in most
examples it is still less noticeable then the noise in darker areas in the same
render.
Differential Revision: https://developer.blender.org/D16392
Without this, a fatal error simply floods the stderr with the same
message without exiting.
Also add note on why reconnecting to the display server isn't practical.
OSD Lists as 0, 0, 0 this is due to opensubdiv_capi.cc not actually including
the OSD version header, so it's not getting the version define, and the code
in openSubdiv_getVersionHex is really well prepared to deal with any or no
version at all of OSD, catches the problem and returns 0, 0, 0
Given this file is only build when OSD is enabled we can just blindly include
opensubdiv/version.h here
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D16398
It wasn't so obvious which functions were part of the GHOST API
and which system functions were utilities.
This convention was already in place but not always followed.
Add a non-blocking version wrapper for wl_display_dispatch_pending.
This uses roughly the same logic as Wayland_PumpEvents in SDL.
Noticed this when investigating T100855.
Note that performing a round-trip doesn't seem necessary from looking
into QT/GTK & SDL event handling loops.
The OSL GPU services implementation of "osl_get_matrix" and
"osl_get_inverse_matrix" was missing support for the "common",
"shader" and "object" matrices and thus any matrix operations in OSL
shaders using these would not work. This patch adds the proper
implementation copied from the OSL CPU services.
Maniphest Tasks: T101222
This patch adapts D14754 for the Metal backend. Kernels of the same type are already organised into subdirectories which simplifies type matching.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D16469
Commit c8dd33f5a37b6a6db0b6950d24f9a7cff5ceb799 in OSL
changed behavior of shader parameters that reference each other
and are also overwritten with an instance value.
This is causing the "NormalIn" parameter of a few OSL nodes in
Cycles to be set to zero somehow, which should instead have
received the value from a "node_geometry" node Cycles generates
and connects automatically. I am not entirely sure why that is
happening, but these parameters are superfluous anyway, since
OSL already provides the necessary data in the global variable "N".
So this patch simply removes those parameters (which mimics
SVM, where these parameters do not exist either), which also
fixes the rendering artifacts that occured with recent OSL.
Maniphest Tasks: T101222
Differential Revision: https://developer.blender.org/D16470
LLVM could kill the process during OSL PTX code generation, due
to generated symbols contained invalid characters in their name.
Those names are generated by Cycles and were not properly filtered:
- If the locale was set to something other than the minimal locale
(when Blender was built with WITH_INTERNATIONAL), pointers
may be printed with grouping characters, like commas or dots,
added to them.
- Material names from Blender may contain the full range of UTF8
characters.
This fixes those cases by forcing the locale used in the symbol name
generation to the minimal locale and using the material name hash
instead of the actual material name string.
Some of the previous commits in Wayland related code added use
of this function, but did not update the dynamic loader. This
broke compilation of configurations which use dynamic loader
for Wayland (which is the official way oh how Blender is built).
rB67e23b4b2967 revealed the bug. But the bug already existed before,
it just wasn't triggered.
Apparently the problem happens because the python code generated in
`initGuiding()` cannot be executed twice.
The second time the `initGuiding()` code is executed, the local python
variables are removed to make way for the others, but the reference to
one of the grids in a `Solver` object (name='solver_guiding2') is still
being used somewhere. So an error is raised and a crash is forced.
The solution is to prevent the python code in `initGuiding()` from being
executed twice.
When `FLUID_DOMAIN_ACTIVE_GUIDE` is in `fds->active_fields` this
indicates that the pointer in `mPhiGuideIn` has been set and the guiding
is already computed (does not need to be computed again).
Maniphest Tasks: T102257
Differential Revision: https://developer.blender.org/D16416
rB67e23b4b2967 revealed the bug. But the bug already existed before,
it just wasn't triggered.
Apparently the problem happens because the python code generated in
`initGuiding()` cannot be executed twice.
The second time the `initGuiding()` code is executed, the local python
variables are removed to make way for the others, but the reference to
one of the grids in a `Solver` object (name='solver_guiding2') is still
being used somewhere. So an error is raised and a crash is forced.
The solution is to prevent the python code in `initGuiding()` from being
executed twice.
When `FLUID_DOMAIN_ACTIVE_GUIDE` is in `fds->active_fields` this
indicates that the pointer in `mPhiGuideIn` has been set and the guiding
is already computed (does not need to be computed again).
Maniphest Tasks: T102257
Differential Revision: https://developer.blender.org/D16416
This patch generalizes the OSL support in Cycles to include GPU
device types and adds an implementation for that in the OptiX
device. There are some caveats still, including simplified texturing
due to lack of OIIO on the GPU and a few missing OSL intrinsics.
Note that this is incomplete and missing an update to the OSL
library before being enabled! The implementation is already
committed now to simplify further development.
Maniphest Tasks: T101222
Differential Revision: https://developer.blender.org/D15902
