| Age | Commit message (Collapse) | Author |
|---|
|
With the change to use render passes internally the alpha channel got lost.
Add support for these render passes to output an alpha channel for baking.
|
|
Still not well defined, but should not longer use uninitialized values that
gave different results between CPU/GPU and subsequent renders.
|
|
|
|
|
|
Move some logic out of triangle intersection functions and into BVH
traversal, so we can share logic between primitives.
Ref D12954
|
|
Ensure valid reflection was moved elsewhere, should not be done in the node
anymore.
|
|
Workaround what may be a compiler bug, solution found by Michael Jones.
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D13759
|
|
Must take into account SD_OBJECT_TRANSFORM_APPLIED to determine if the normal
was already in world space.
Differential Revision: https://developer.blender.org/D13639
|
|
This patch fixes a couple of new Metal kernel compilation errors: 1) a kernel parameter count overflow, and 2) missing address space qualifiers.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13763
|
|
Enables the `bpy.ops.cycles.denoise_animation()` operator again and modifies it to support
temporal denoising with OptiX. This requires renders that were done with both the "Vector"
and "Denoising Data" passes.
Differential Revision: https://developer.blender.org/D11442
|
|
in Cycles kernel code
Occured because "PATH_RAY_SHADOW_CATCHER_BACKGROUND" is expressed as an unsigned
integer, because too large for a signed integer, but the "PathRayFlag" enum type defaulted to a
signed integer still.
|
|
Refactor code a bit also so we need to do fewer matrix transforms for shader
data setup of points and curves.
|
|
Includes refactoring to reduce the number of bits taken by primitive types,
so they more easily fit in the OptiX limit.
|
|
Missing ccl_private form an older patch.
Differential Revision: https://developer.blender.org/D13612
|
|
|
|
This add support for rendering of the point cloud object in Blender, as a native
geometry type in Cycles that is more memory and time efficient than instancing
sphere meshes. This can be useful for rendering sand, water splashes, particles,
motion graphics, etc.
Points are currently always rendered as spheres, with backface culling. More
shapes are likely to be added later, but this is the most important one and can
be customized with shaders.
For CPU rendering the Embree primitive is used, for GPU there is our own
intersection code. Motion blur is suppored. Volumes inside points are not
currently supported.
Implemented with help from:
* Kévin Dietrich: Alembic procedural integration
* Patrick Mourse: OptiX integration
* Josh Whelchel: update for cycles-x changes
Ref T92573
Differential Revision: https://developer.blender.org/D9887
|
|
|
|
This replaces lost functionality from the old GN Attribute Map Range node.
This also adds vector support to the shader version of the node.
Notes:
This breaks forward compatibility as this node now uses data storage.
Reviewed By: HooglyBoogly, brecht
Differential Revision: https://developer.blender.org/D12760
|
|
render crash. (ARM/Metal)
This fixes crash T94022 when selecting live viewport render with both GPU & CPU devices selected. It is caused by incorrect `KernelBVHLayout` assignment. Similar to `BVH_LAYOUT_MULTI_OPTIX` for Optix, this patch adds a `BVH_LAYOUT_MULTI_METAL` to correctly redirect to the correct Metal BVH layout type.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13561
|
|
with the CPU and GPU
When rendering volume surfaces in unbounded worlds the volume stepping can produce large values. If used with a magic texture node the values can results in a Inf float which when used in a sin or cos produces a NaN.
To fix this the input values are mapped into the periodic range of the sin and cos functions (-2*PI 2*PI) this stops the possibility of a Inf occurring and thus the NaN. It also improves the accuracy and smoothness of the result due to loss of precision when large values are summed with smaller ones effectively removing the parts of the smaller number (i.e. those in the -2PI to 2PI range) that result in variation of the output of sin and cos.
Reviewed By: brecht
Maniphest Tasks: T92036
Differential Revision: https://developer.blender.org/D12821
|
|
|
|
|
|
This allows real world cameras to be modeled by specifying the coordinates of a
4th degree polynomial that relates a pixels distance (in mm) from the optical
center on the sensor to the angle (in radians) of the world ray that is
projected onto that pixel.
This is available as part of the panoramic lens type, however it can also be
used to model lens distortions in projective cameras for example.
Differential Revision: https://developer.blender.org/D12691
|
|
Differential Revision: https://developer.blender.org/D13468
|
|
This patch adds the Metal host-side code:
- Add all core host-side Metal backend files (device_impl, queue, etc)
- Add MetalRT BVH setup files
- Integrate with Cycles device enumeration code
- Revive `path_source_replace_includes` in util/path (required for MSL compilation)
This patch also includes a couple of small kernel-side fixes:
- Add an implementation of `lgammaf` for Metal [Nemes, Gergő (2010), "New asymptotic expansion for the Gamma function", Archiv der Mathematik](https://users.renyi.hu/~gergonemes/)
- include "work_stealing.h" inside the Metal context class because it accesses state now
Ref T92212
Reviewed By: brecht
Maniphest Tasks: T92212
Differential Revision: https://developer.blender.org/D13423
|
|
|
|
* Spot lights are now handled as disks aligned with the direction of the
spotlight instead of view aligned disks.
* Point light is now handled separately from the spot light, to fix a case
where multiple lights are intersected in a row. Before the origin of the
ray was the previously intersected light and not the origin of the initial
ray traced from the last surface/volume interaction.
This makes both strategies in multiple importance sampling converge to the same
result. It changes the render results in some scenes, for example the junkshop
scene where there are large point lights overlapping scene geometry and each
other.
Differential Revision: https://developer.blender.org/D13233
|
|
|
|
|
|
|
|
Found in D13353, likely has no significant impact in performance.
|
|
This patch adds MetalRT support to Cycles kernel code. It is mostly additive in nature or confined to Metal-specific code, however there are a few areas where this interacts with other code:
- MetalRT closely follows the Optix implementation, and in some cases (notably handling of transforms) it makes sense to extend Optix special-casing to MetalRT. For these generalisations we now have `__KERNEL_GPU_RAYTRACING__` instead of `__KERNEL_OPTIX__`.
- MetalRT doesn't support primitive offsetting (as with `primitiveIndexOffset` in Optix), so we define and populate a new kernel texture, `__object_prim_offset`, containing per-object primitive / curve-segment offsets. This is referenced and applied in MetalRT intersection handlers.
- Two new BVH layout enum values have been added: `BVH_LAYOUT_METAL` and `BVH_LAYOUT_MULTI_METAL_EMBREE` for XPU mode). Some host-side enum case handling has been updated where it is trivial to do so.
Ref T92212
Reviewed By: brecht
Maniphest Tasks: T92212
Differential Revision: https://developer.blender.org/D13353
|
|
This patch fixes an address space mismatch in the film convert kernels on Metal. The `film_get_pass_pixel_...` functions take a `ccl_private` result pointer, but the film convert kernels pass a `ccl_global` memory pointer. Specialising the pass-fetch functions with templates results in compilation errors on Visual Studio, so instead this patch just adds an intermediate local on Metal.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13350
|
|
|
|
Was happening during rendering, causing visual artifacts when doing
CPU+GPU rendering, and giving different in-progress results on different
devices.
The root of the issue comes to the fact that math used in the approximate
shadow catcher calculation might have resulted in negative alpha channel,
and negative values for display are handled differently on CPU and GPU.
Such difference in handling is caused by an approximate conversion used on
the CPU for the performance reasons.
This change makes it so no negative alpha is generated by the approximate
shadow catcher. Not sure if we need some explicit clamping somewhere to
deal with possible negative values coming from somewhere else.
The shadow catcher cornell box tests are to be updated for the new code,
but the new result seems to be more accurate.
Differential Revision: https://developer.blender.org/D13354
|
|
Fix performance decrease with Scrambling Distance on
|
|
With the current code in master, scrambling distance is enabled on non-hardware accelerated ray tracing devices see a measurable performance decrease when compared scrambling distance on vs off. From testing, this performance decrease comes from the large tile sizes scheduled in `tile.cpp`.
This patch attempts to address the performance decrease by using different algorithms to calculate the tile size for devices with hardware accelerated ray traversal and devices without. Large tile sizes for hardware accelerated devices and small tile sizes for others.
Most of this code is based on proposals from @brecht and @leesonw
Reviewed By: brecht, leesonw
Differential Revision: https://developer.blender.org/D13042
|
|
catmull-rom curve type
Some enum names were changed/removed in OptiX 7.4, so some changes are necessary to
make things compile still.
In addition, OptiX 7.4 also adds built-in support for catmull-rom curves, so it is no longer
necessary to convert the catmull-rom data to cubic bsplines first, and has endcaps disabled
by default now, so can remove the special handling via any-hit programs that filtered them
out before.
Differential Revision: https://developer.blender.org/D13351
|
|
|
|
Happened in barbershop file where number of bounces to the light was
reached.
Differential Revision: https://developer.blender.org/D13336
|
|
|
|
BVH2 triangle intersection was broken on the GPU since packed floats can't
be loaded directly into SSE. The better long term solution for performance
would be to build a BVH2 for GPU and Embree for CPU, similar to what we do
for OptiX.
|
|
|
|
|
|
With very long ray distance, OptiX ends up traversing many BVH nodes due to
a feature that improves precision. However this causes very slow rendering.
We now avoid generating such long rays by rejecting the few samples that have
long ray distances and very low probability of being generated. This should not
meaningfully affect render results.
Thanks to Sergey and Patrick for the investigation.
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D10447
|
|
|
