After spending way too much time looking into the image handle code
because I assumed the issue is some interaction between OSL code using
a texture and the image system that's in SVM mode (which never happened
before the custom camera) with printf debuggine because OptiX doesn't
work in debug builds, it turns out the issue was something else entirely:
C++ iterator bullshit.
Specifically, when we remove an entry from services->textures, this
invalidates the iterator, so the code restarts from the beginning.
However, the for-loop still increments the iterator *before* checking
the termination criterion.
If we remove the only element of the map, we:
- Set it = map.begin(), which equals map.end() since it's empty now
- Increment it at the end of the loop iteration
- Compare it == map.end(), which is wrong now since we're past the end
No idea how this didn't blow up sooner, none of this seems camera-specific??
Anyways, the fix is simple - only increment if we didn't restart.
Pull Request: https://projects.blender.org/blender/blender/pulls/141580
This allows users to implement arbitrary camera models using OSL by writing
shaders that take an image position as input and compute ray origin and
direction.
The obvious applications for this are e.g. panorama modes, lens distortion
models and realistic lens simulation, but the possibilities are endless.
Currently, this is only supported on devices with OSL support, so CPU and
OptiX. However, it is independent from the shading model used, so custom
cameras can be used without getting the performance hit of OSL shading.
A few samples are provided as Text Editor templates.
One notable current limitation (in addition to the limited device support)
is that inverse mapping is not supported, so Window texture coordinates and
the Vector pass will not work with custom cameras.
Pull Request: https://projects.blender.org/blender/blender/pulls/129495
Add support for OSL parameter metadata named `defaultgeomprop`, whose
values are interpreted the same way as the property on MaterialX node
inputs. When set to `Tworld` the tangent is then automatically linked
to the shader and generated for the mesh.
Pull Request: https://projects.blender.org/blender/cycles/pulls/25
This is preparation for #129495.
Currently, all of OSL is managed by the OSLShaderManager. This makes it so that the general OSL setup is handled by a general OSLManager, and both the OSLShaderManager and (in the future) the Camera can use it to manage their scripts.
Pull Request: https://projects.blender.org/blender/blender/pulls/135050
Check was misc-const-correctness, combined with readability-isolate-declaration
as suggested by the docs.
Temporarily clang-format "QualifierAlignment: Left" was used to get consistency
with the prevailing order of keywords.
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
* Use .empty() and .data()
* Use nullptr instead of 0
* No else after return
* Simple class member initialization
* Add override for virtual methods
* Include C++ instead of C headers
* Remove some unused includes
* Use default constructors
* Always use braces
* Consistent names in definition and declaration
* Change typedef to using
Pull Request: https://projects.blender.org/blender/blender/pulls/132361
The original OSL Shading System API was stateful: You'd create a shader
group, configure it, and then end it. However, this means that only one
group can be created at a time. Further, since Cycles reuses the
Shading System for multiple instances (e.g. viewport render and
material preview), a process-wide mutex is needed.
However, for years now OSL has had a better interface, where you
explicitly provide the group you refer to. With this, we can not only
get rid of the mutex, but actually multi-thread the shader setup even
within one instance.
Realistically, most time is still spent in the JIT stage, but it's
still better than nothing.
Pull Request: https://projects.blender.org/blender/blender/pulls/130133
Based on #123377 by @brecht, but Gitea doesn't like the rebase these
so here's a new PR.
The purpose here is to switch to fused OptiX programs for OSL execution
on CUDA. On the one hand, this makes the code easier since, but there's
also another advantage - how memory allocation is managed.
OSL shaders need memory to store intermediate values, but how much is
needed depends on the complexity of the shader. With the split program
approach, Cycles had to provide that memory, so we had to allocate a
certain amount (2 KiB, to be precise) statically and show an error if
the shader would need more. If the shader used less (which is the case
for the vast majority), the memory was just wasted.
By switching to fused kernels, OSL knows the required amount during JIT
codegen, so it can allocate only what's required, which avoids this
waste. One still needs to set a maximum, and in theory, OSL would also
support spilling over into a Cycles-provided alternative memory region.
However, we currently don't implement that - instead, we default to the
same 2048 limit as before and let advanced users override it via the
CYCLES_OSL_GROUPDATA_ALLOC environment variable if really needed.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/130149
In the commonly used cycles headers, it's enough to include
much smaller <iosfwd> than the full <iostream>. While looking at it,
removed inclusion of some other headers from commonly used headers,
that seemed to not be needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/111063
this option was already unselectable in the UI, and is treated as GGX
with zero roughness. Upon building the shader graph, we only convert a
closure to `SHARP` when option Filter Glossy is not used and the
roughness is below certain threshold. The benefit is that we can avoid
calling `bsdf_eval()` or return earlier in some cases, but the thresholds
vary across files.
This patch removes `SHARP` closures altogether, and checks if the
roughness value is below a global threshold `BSDF_ROUGHNESS_THRESH`
after blurring, in which case the flag `SD_BSDF_HAS_EVAL` is not set.
The global threshold is set to be `5e-7f` because threshold smaller than
that seems to have caused problem in the past (c6aa0217ac). Also removes
a bunch of functions, variables and arguments that were only there
because we converted closures under certain conditions.
Pull Request: https://projects.blender.org/blender/blender/pulls/109902
For example
```
OIIOOutputDriver::~OIIOOutputDriver()
{
}
```
becomes
```
OIIOOutputDriver::~OIIOOutputDriver() {}
```
Saves quite some vertical space, which is especially handy for
constructors.
Pull Request: https://projects.blender.org/blender/blender/pulls/105594
Removing all OSL script nodes from the shader graph would cause that
graph to no longer report it using `KERNEL_FEATURE_SHADER_RAYTRACE`
via `ShaderManager::get_graph_kernel_features`, but the shader object
itself still would have the `has_surface_raytrace` field set.
This caused kernels to be reloaded without shader raytracing support, but
later the `DEVICE_KERNEL_INTEGRATOR_SHADE_SURFACE_RAYTRACE`
kernel would still be invoked since the shader continued to report it
requiring that through the `SD_HAS_RAYTRACE` flag set because of
`has_surface_raytrace`.
Fix that by ensuring `has_surface_raytrace` is reset on every shader update,
so that when all OSL script nodes are deleted it is set to false, and only
stays true when there are still OSL script nodes (or other nodes using it).
Maniphest Tasks: T104157
Differential Revision: https://developer.blender.org/D17140
The background evaluation samples the sky discretely, so if the sun is
too small, it can be missed in the evaluation. To solve this, the sun is
ignored during the background evaluation and its contribution is
computed separately.
This makes it possible to use `texture` and `texture3d` in custom
OSL shaders with a constant image file name as argument on the
GPU, where previously texturing was only possible through Cycles
nodes.
For constant file name arguments, OSL calls
`OSL::RendererServices::get_texture_handle()` with the file name
string to convert it into an opaque handle for use on the GPU.
That is now used to load the respective image file using the Cycles
image manager and generate a SVM handle that can be used on
the GPU. Some care is necessary as the renderer services class is
shared across multiple Cycles instances, whereas the Cycles image
manager is local to each.
Maniphest Tasks: T101222
Differential Revision: https://developer.blender.org/D17032
Materials now have an enum to set the emission sampling method, to be
either None, Auto, Front, Back or Front & Back. This replace the
previous "Multiple Importance Sample" option.
Auto is the new default, and uses a heuristic to estimate the emitted
light intensity to determine of the mesh should be considered as a light
for sampling. Shaders sometimes have a bit of emission but treating them
as a light source is not worth the memory/performance overhead.
The Front/Back settings are not important yet, but will help when a
light tree is added. In that case setting emission to Front only on
closed meshes can help ignore emission from inside the mesh interior that
does not contribute anything.
Includes contributions by Brecht Van Lommel and Alaska.
Ref T77889
When either initializing with a non-constant value, or using the standard
[[ string widget = "null" ]] metadata. This can be used for inputs like
normals and texture coordinates, where you don't want to default to a
constant value.
In previous OSL versions the input value was automatically ignore when it
was left unchanged for such inputs. However that's no longer the case in
the latest version, breaking existing nodes. There is no good entirely
backwards compatible fix, but I believe the new behavior is better and will
keep most existing cases working.
Fix T102450: OSL node with normal input not working
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.
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
Cleans up the file structure to be more similar to that of the SVM
and also makes it possible to build kernels with OSL support, but
without having to include SVM support.
This patch was split from D15902.
Differential Revision: https://developer.blender.org/D15949
This has the advantage of being able to use information about the
existing OSL closures in various places without code duplication. In
addition, the setup code for all closures was moved to standalone
functions to avoid usage of virtual function calls in preparation for GPU
support.
This patch was split from D15902.
Differential Revision: https://developer.blender.org/D15917
