The problem here was numerical precision: The code calculates the angle between
sun and view direction, and the usual acos(dot(a, b)) approach for that has
poor numerical performance for almost parallel angles.
As a result, the generally tiny difference between floating point computation
between CPU and GPU was enough to make the sun vanish at different radii,
causing different results.
The new version fixes the difference by making the computation much more robust
on both platforms.
This patch adds support for the curve primitive from OptiX to Cycles. It's currently hidden
behind a debug option, since there can be some slight rendering differences still (because no
backface culling is performed and something seems off with endcaps). The curve primitive
was added with the OptiX 7.1 SDK and requires a r450 driver or newer, so this also updates
the codebase to be able to build with the new SDK.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8223
Don't apply the matrix transform optimization in this case, curve points and
radius can't represent non-uniform scale the way is possible with triangle
meshes and vertices.
This would cause abrupt change if objects had e.g. motion blur in one frame
and not in the next.
The unit being "pixels".
Before this change the solve errors were unitless in the UI.
With this change in place, the UI is now clear on that the unit of the
reprojection errors is pixels (px).
Differential Revision: https://developer.blender.org/D8000
Denoising devices do not need to load the full feature set of kernels, so only activate the denoising
feature for them (so that it is possible to use features that are supported by the render devices, but
not the denoising devices).
For historical reasons, `DupliObject::persistent_id` was of size
`2*MAX_DUPLI_RECUR`. These reasons are now gone, and the persistent ID
always gets exactly one array element for every dupli-recursion.
Differential Revision: https://developer.blender.org/D8222
Reviewed by: brecht
The issue is duplicated code. There are two functions that zero-fill
the frame number. They worked the same for positive frames numbers, but
behaved differently for negative ones.
On frame `-100`, `BLI_path_frame` outputs `-0100` and
`fluid_cache_get_framenr_formatted_$ID$` outputted `-100`.
I changed the behavior of the latter, because we depend on the behavior
of the former for much longer already.
Reviewers: sebbas
Differential Revision: https://developer.blender.org/D8107
Changed variable names from mmd, mds, mfs, and mes to fmd, fds, ffs, and fes. The author of this commits lights a candle for all the merge conflicts this will cause.
First benefit is reduced boilerplate code.
Second benefit is fixed warnings about using deprecated spin lock
on macOS when using SDK 10.12 and above.
Differential Revision: https://developer.blender.org/D8182
Apply the workaround only for known problematic drivers. The latest pro driver
appears to work correctly, hopefully the regular driver will as well once it
is updated to the same OpenCL driver version (3075.13).
Always initialize the particle velocity of newly sampled particles to 0 if there are no initial velocities. Clearing the grid source makes sure that new particles will get a 0 velocity - and not interpolated from the associated grid.
Latest SteamVR OpenXR updates brought OpenGL support, but only with sRGB
buffers. I think for DirectX it's the same now.
It's not a big issue for us to use sRGB buffers, so that's what I will
do for now. That way we shouldn't need hardcoded exceptions for specific
runtimes that don't transform linear buffers correctly.
When we switched to MSVC2019 and C++17 we seemingly
managed to trigger a code-gen bug with MSVC in the
AVX code-path.
This change works around the issue by (hopefully
temporary) disabling the optimizer for the fast_exp2f4
function, given it is only used in a single pass
of the denoiser and nowhere else, this is luckily
not as bad as it could have been.
Once the compiler is fixed or a different fix is
available we'll have to revisit this.
Details and link to the repro posted to MS is
available in T78047
This commit makes uses of the new OpenVDB IO in Mantaflow (introduced in 781f783a66ac).
From now on, fluid cache files in OpenVDB format will contain a list of grids per frame (before: one .vdb file per grid per frame). Besides regular grids, particle systems are also stored using OpenVDBs PointGrid data structures.
All older cache formats will remain fully functional:
- Uni caches (.uni) files are still available from the UI and can be used as before
- Raw caches (.raw) are no longer available from the UI, but loading them is still possible
- Old OpenVDB caches (one .vdb per grid) can no longer be baked either, but loading them is still possible.
It is also no longer possible to choose file formats for 'Noise' and 'Particles'. Instead there are now options to set the file format for 'Volumetric' and for 'Mesh' data.
Known issues (planned to be resolved soon):
- OpenVDB files are currently not taking into consideration the clipping value (FluidDomainSettings). Empty cells are therefore being written too. Depending on the scene, this can make file sizes unnecessarily large.
- Domains are not being exported at their world position. Instead they are always clipped to the origin.
