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 SubdAttributeInterpolation class for linear attribute interpolation.
* Dicing computes ptex UV and face ID for interpolation.
* Simplify mesh storage of subd primitive counts
* Remove kernel code for subd attribute interpolation
* Remove patch table packing and upload
The old optimization adds a fair amount of complexity to the kernel, affecting
performance even when not using the feature. It's also not that useful as it
does not work for UVs that needs special interpolation. With this simpler code
it should be easier to make it feature complete.
Pull Request: https://projects.blender.org/blender/blender/pulls/135681
This is an intermediate steps towards making lights actual geometry.
Light is now a subclass of Geometry, which simplifies some code.
The geometry is not added to the BVH yet, which would be the next
step and improve light intersection performance with many lights.
This makes object attributes work on lights.
Co-authored-by: Lukas Stockner <lukas@lukasstockner.de>
Pull Request: https://projects.blender.org/blender/blender/pulls/134846
The attribute handling code in the kernel is currently highly duplicated since
it needs to handle five different data types and we couldn't use templates
back then.
We can now, so might as well make use of it and get rid of ~1000 lines.
There are also some small fixes for the GPU OSL code:
- Wrong derivative for .w component when converting float2/float3->float4
- Different conversion for float2->float (CPU averages, GPU used to take .x)
- Removed useless code for converting to float2, not used by OSL
Pull Request: https://projects.blender.org/blender/blender/pulls/134694
This commit fixes a issue where ray depth for emissive objects
(E.g. Lights) was incorrect when using the ray depth output of the
light path node in Cycles OSL.
Pull Request: https://projects.blender.org/blender/blender/pulls/134496
This commit adds the `light:random` attribute to OSL, allowing the
object info node to now match between SVM and OSL when using the
random output on a light.
Pull Request: https://projects.blender.org/blender/blender/pulls/134095
The derivatives of the normal were simply not computed.
The offsetted normals are computed by perturbating the barycentric
coordinates. At triangle boundaries, the normals are extrapolated,
so discontinuities might be visible.
Currently only supported on triangles.
Pull Request: https://projects.blender.org/blender/blender/pulls/133769
That version has a bunch of API changes, so by dropping support for older
versions we can remove old compatibility code.
Also, that version is required for OptiX support, so building a fully-featured
Cycles wasn't possible with older OSL anyways.
Pull Request: https://projects.blender.org/blender/blender/pulls/133746
OSL has OSL::ShaderGlobals, which contains all the state for OSL shader
execution. The renderer fills it out and hands a pointer to OSL, and any
callbacks (e.g. for querying attributes) get the pointer back.
In order to store renderer-specific data in it, there's a few opaque pointers
in the struct, but using those has led to a mess of reinterpret_cast<> and
pointer indirection in order to carry all the data around.
However, there is a way to do this nicer: Good old C-style struct inheritance.
In short: Unless you're doing pointer arithmetic, you can just add additional
data at the end of a base struct, and the rest of the code won't care.
In this case, this means that we can have our own ShaderGlobals struct and
add more Cycles-specific data at the end. Additionally, we can replace the
generic opaque void pointers with ones of the correct type, which saves us
from needing to cast them back.
Since we have a copy of ShaderGlobals for GPU OSL anyways, it's just a matter
of refactoring the code a bit to make use of that.
The advantages of this are:
- Avoids casts all over the place, just needs one cast to turn our
ShaderGlobals into the "base" type that OSL expects and one to turn the
pointer that OSL gives us on callbacks back into our "derived" type.
- Removes indirection, all the relevant stuff (sd, kg, state) is now
directly in the ShaderGlobals
- Removes some OSL-specific state from ShaderData, which helps to keep
memory usage down
Pull Request: https://projects.blender.org/blender/blender/pulls/133689
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
After e3697710d0, if no UV map was found, then Cycles OSL would
generate UV coordinates for users. This was done to add UV coordinates
to lights, however it had the side effect of creating new UV
coordinates for other object types that don't have a UV map.
This lead to a rendering difference between OSL and SVM
when rendering meshes with no UV map, and objects with no
UV map, like curves.
This commit fixes this issue by adding a new "is_light" attribute to
Cycles OSL and using that to figure out if UV coordinates should be
generated for lights.
Pull Request: https://projects.blender.org/blender/blender/pulls/124673
The motivation is to be able to catch issues like #124705 early on,
by relying on asserts.
The not-so-obvious part of the change is the change in the order of
includes, which is needed for the types.h to have definition of the
kernel_assert().
Pull Request: https://projects.blender.org/blender/blender/pulls/124729
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
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
wi is the viewing direction, and wo is the illumination direction. Under this notation, BSDF sampling always samples from wi and outputs wo, which is consistent with most of the papers and mitsuba. This order is reversed compared with PBRT, although PBRT also traces from the camera.
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
The SVM attribute map is always generated and uses a simple
linear search to lookup by an opaque ID, so can reuse that for OSL
as well and simply use the attribute name hash as ID instead of
generating a unique value separately. This works for both object
and geometry attributes since the SVM attribute map already
stores both. Simplifies code somewhat and reduces memory
usage slightly.
This patch was split from D15902.
Differential Revision: https://developer.blender.org/D15918
* Store compact ray differentials in ShaderData and compute full differentials
on demand. This reduces register pressure on the GPU.
* Remove BSDF differential code that was effectively doing nothing as the
differential orientation was discarded when making it compact.
This gives a 1-5% speedup with RTX A6000 + OptiX in our benchmarks, with the
bigger speedups in simpler scenes.
Renders appear to be identical except for the Both displacement option that
does both displacement and bump.
Differential Revision: https://developer.blender.org/D15677
For transparency, volume and light intersection rays, adjust these distances
rather than the ray start position. This way we increment the start distance
by the smallest possible float increment to avoid self intersections, and be
sure it works as the distance compared to be will be exactly the same as
before, due to the ray start position and direction remaining the same.
Fix T98764, T96537, hair ray tracing precision issues.
Differential Revision: https://developer.blender.org/D15455
