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.
Compared to Optix denoise, this is usually slower since there is no GPU
acceleration. Some optimizations may still be possible, in avoid copies
to the GPU and/or denoising less often.
The main thing is that this adds viewport denoising support for computers
without an NVIDIA GPU (as long as the CPU supports SSE 4.1, which is nearly
all of them).
Ref T76259
Enabling render and viewport denoising is now both done from the render
properties. View layers still can individually be enabled/disabled for
denoising and have their own denoising parameters.
Note that the denoising engine also affects how denoising data passes are
output even if no denoising happens on the render itself, to make the passes
compatible with the engine.
This includes internal refactoring for how denoising parameters are passed
along, trying to avoid code duplication and unclear naming.
Ref T76259
This replaces the cmake options `WITH_NEW_OBJECT_TYPES` and
`WITH_NEW_SIMULATION_TYPE` with two experimental userpref settings:
* `use_new_particle_system`: Enables the point cloud type and the simulation editor.
* `use_new_hair_type`: Only displays the add-operator in the add menu for now.
Note, in the current state you can't do anything productive with the new particle
system or the new hair type. Features will be added step by step in the upcoming
weeks and months.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D8096
For GPU debugging purposes, it is still possible to render with the same BVH2
on the CPU using the Debug panel in the render properties.
Note that building Blender without Embree will now lead to significantly reduced
performance in CPU rendering, and a few of the Cycles regression tests will fail
due to small pixel differences.
Ref T73778
Depends on D8014
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8015
Also removing the curve system manager which only stored a few curve intersection
settings. These are all changes towards making shape and subdivision settings
per-object instead of per-scene, but there is more work to do here.
Ref T73778
Depends on D8013
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8014
This keeps render results compatible for combined CPU + GPU rendering.
Peformance and quality primitives is quite different than before. There
are now two options:
* Rounded Ribbon: render hair as flat ribbon with (fake) rounded normals, for
fast rendering. Hair curves are subdivided with a fixed number of user
specified subdivisions.
This gives relatively good results, especially when used with the Principled
Hair BSDF and hair viewed from a typical distance. There are artifacts when
viewed closed up, though this was also the case with all previous primitives
(but different ones).
* 3D Curve: render hair as 3D curve, for accurate results when viewing hair
close up. This automatically subdivides the curve until it is smooth.
This gives higher quality than any of the previous primitives, but does come
at a performance cost and is somewhat slower than our previous Thick curves.
The main problem here is performance. For CPU and OpenCL rendering performance
seems usually quite close or better for similar quality results.
However for CUDA and Optix, performance of 3D curve intersection is problematic,
with e.g. 1.45x longer render time in Koro (though there is no equivalent quality
and rounded ribbons seem fine for that scene). Any help or ideas to optimize this
are welcome.
Ref T73778
Depends on D8012
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8013
The kernel did not work correctly when these were disabled anyway. The
optimized BVH traversal for the no instances case was also only used on
the CPU, so no longer makes sense to keep.
Ref T73778
Depends on D8010
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8011
The hair BSDFs are already designed to assume this, and disabling backface
culling would break them in some cases.
Ref T73778
Depends on D8009
Maniphest Tasks: T73778
Differential Revision: https://developer.blender.org/D8010
Triangles were very memory intensive. The only reason they were not removed yet
is that they gave more accurate results, but there will be an accurate 3D curve
primitive added for this.
Line rendering was always poor quality since the ends do not match up. To keep CPU
and GPU compatibility we just remove them entirely. They could be brought back if
an Embree compatible implementation is added, but it's not clear to me that there
is a use case for these that we'd consider important.
Ref T73778
Reviewers: #cycles
Subscribers:
No significant performance improvement is expected, but it means we have a
single thread pool throughout Blender. And it should make adding more
parallellization in the future easier.
After previous refactoring commits this is basically a drop-in replacement.
One difference is that the task pool had a mechanism for scheduling tasks to
the front of the queue to minimize memory usage. TBB has a smarter algorithm
to balance depth-first and breadth-first scheduling of tasks and we assume that
removes the need to manually provide hints to the scheduler.
Fixes T77533
OSLRenderServices contains a member which is 64 bytes aligned and this
is onlys supported by default allocators in SDK 10.14. Since we take
care of allocation ourselves ignoring the diagnostic is an acceptable
way dealign with it.
Using latest master because of various compilation error fixes.
Brings a lot of recent development. From most interesting parts:
- New threading model.
- Tiny solver.
- Compatibility with C++17.
This seems to be an error in rBb91b90f0dd3c9bff3b1a6e563c2cce293722ed16.
I found it, because I could not open the file in T77263 anymore.
Reviewers: sebbas
Differential Revision: https://developer.blender.org/D8065
This commit adds a new model to the Sky Texture node, which is based on a
method by Nishita et al. and works by basically simulating volumetric
scattering in the atmosphere.
By making some approximations (such as only considering single scattering),
we get a fairly simple and fast simulation code that takes into account
Rayleigh and Mie scattering as well as Ozone absorption.
This code is used to precompute a 512x128 texture which is then looked up
during render time, and is fast enough to allow real-time tweaking in the
viewport.
Due to the nature of the simulation, it exposes several parameters that
allow for lots of flexibility in choosing the look and matching real-world
conditions (such as Air/Dust/Ozone density and altitude).
Additionally, the same volumetric approach can be used to compute absorption
of the direct sunlight, so the model also supports adding direct sunlight.
This makes it significantly easier to set up Sun+Sky illumination where
the direction, intensity and color of the sun actually matches the sky.
In order to support properly sampling the direct sun component, the commit
also adds logic for sampling a specific area to the kernel light sampling
code. This is combined with portal and background map sampling using MIS.
This sampling logic works for the common case of having one Sky texture
going into the Background shader, but if a custom input to the Vector
node is used or if there are multiple Sky textures, it falls back to using
only background map sampling (while automatically setting the resolution to
4096x2048 if auto resolution is used).
More infos and preview can be found here:
https://docs.google.com/document/d/1gQta0ygFWXTrl5Pmvl_nZRgUw0mWg0FJeRuNKS36m08/view
Underlying model, implementation and documentation by Marco (@nacioss).
Improvements, cleanup and sun sampling by @lukasstockner.
Differential Revision: https://developer.blender.org/D7896
This patch makes the infamous "Cancel" error in the viewport a thing of the past. Instead it
now shows a more useful error message and streamlines the error handling process in CUDA.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8008
Steam just released a SteamVR update with OpenXR Developer Preview
support:
https://steamcommunity.com/games/250820/announcements/detail/2396425843528787270.
Once SteamVR is set up for OpenXR (see link above), it works with
Blender "out of the box", thanks to OpenXR!
We have to apply the sRGB transform workaround for SteamVR though,
otherwise it renders way too dark. Done in the next commit.
Note that AMD users may still only see a pink screen, because the
OpenGL-DirectX compatibility fails. I will check on a fix again.
For SteamVR on Linux we may have to wait for until it supports OpenGL
rendering for OpenXR. Alternatively, we *could* add initial Vulkan
support at Ghost level and use Vulkan<->OpenGL interoperability
extensions, Monado uses these as well.
When closing the File Browser window after making it fullscreen, Blender would
either crash or all windows would disappear, with no obvious way to bring them
back.
The "fix" is to not allow fullscreen for File Browsers (or any future "dialog"
windows), but only maximizing. From what I can tell that's how secondary
windows are supposed to work on macOS. What we previously did seemed like
something macOS doesn't handle cleanly, and I didn't find a simple way to do so
on our side.
With this patch Cycles recognizing when a logical OptiX and CUDA device represent the same
physical GPU and attempts to eliminate unnecessary tile copies for viewport rendering if that
is the case for all active devices. In addition, denoising is now no longer performed on the first
available OptiX device only, but instead it will try to match CUDA and OptiX
rendering/denoising devices exactly to maximize utilization.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7975
This code is currently only used for the Glossy Toon BSDF, but it's a generic
building block that might be used for other things in the future.
To see why the current code does not give a uniform distribution, consider that
it chooses both angles uniformly, but the smaller the angle from the center of
the cone is, the smaller the differential solid angle is (similar to how
sampling disks by choosing radius and phi uniformly does not work).
Differential Revision: https://developer.blender.org/D7948
This change modifies the multi-device implementation to support memory distribution
across devices, to reduce the overall memory footprint of large scenes and allow scenes to
fit entirely into combined GPU memory that previously had to fall back to host memory.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7426
This reverts commit 33ce0cb5a1.
Fix T77273: crash enabling portal lights. The optimization for background
updates can be added back later for 2.90 and 2.83.1.
This remove the complexity of queriying the locations at runtime and
allows for more performance and upfront binding specifications.
The benefit of doing everything at creation time is that we can assign binding
points in a predictable order which is going to be somewhat the same for
every similar shader.
This also rewrite GPU_vertformat_from_shader to not use shaderface.
This is to keep the shaderface simple. If it becomes necessary to not query
the shader after creation (i.e: vulkan?) we could just create the vert
format in advance at compilation for PyGPU shaders.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D7879
A new user parameter can be used to shift the shadow terminator
towards the light source. With it, one can hide some of the
artifacts that appear on coarse meshes with smooth shading.
Note that this technique is not engery conserving.
This is based on the work by the Appleseed renderer team.
Differential Revision: https://developer.blender.org/D7634
The input data to the OptiX denoiser was clamped to 0..10000 as required, but it could easily
exceed that range with a high number of samples (since the data contains the overall sum). To
fix that, divide by the number of samples first and multiply it back in after the denoiser ran.
This change makes it so vertices of edge are only stored when edge
has non-zero crease. This allows to lower memory footprint of 1.5M
faces from 78 MiB to 54 MiB in the case all creases are zero.
Meshes with crease are more hard to predict due to array-based
storage, so it all depends on index of edge with crease. Worst case
(all edges are creased) still stays at 78 MiB.
Makes it possible to set adjacent vertices after edge sharpness.
Initially it seemed like useful sanity check, but with time it
became rather a burden.
Avoid per-face pointer and allocation: store everything as continuous
arrays.
Memory footprint for 1.5M faces:
- Theoretical worst case (all vertices and edges have crease) memory
goes down from 114 MiB to 96 MiB (15% improvement).
This case is not currently achievable since Blender does not expose
vertex crease yet.
- Current real life worst case (all edges have crease) memory goes
down from 108 MiB to 90 MiB (17% improvement).
- Best case (no creases at all) memory goes down from 96 MiB to 78 MiB
(19% improvement).
While this looks trivial it already allowed to catch issues in one
of previous attempt to optimize memory usage. It will totally be
useful for an upcoming refactor of face topology storage.
Allows to perform comparison by doing linear comparison of indices.
Before cyclic match was used to deal with possibly changed winding from
OpenSubdiv side.
Speeds up comparison (and hence improves FPS), makes code more reliable
nut uses more memory.
This change makes it so topology refiner comparison will check vertices
of all existing/provided edges.
The initial claim that due to manifold nature of mesh there is no need
in "deep" edges check was wrong: some areas might only provide edges
with non-zero creases. So if crease of one edge goes changes from 1.0
to 0.0 and crease of other edge goes from 0.0 to 1.0 the old comparison
code would not have caught it.
Brecht Van Lommel
Adrian Newton
Brecht Van Lommel
Sebastián Barschkis
Campbell Barton
Jens Verwiebe
Julian Eisel
Ray Molenkamp
Aaron Carlisle
Jacques Lucke
Hans Goudey
Sergey Sharybin
Lukas Stockner
Patrick Mours
Tautvydas Andrikys
Clément Foucault
Johan Walles
Stefan Werner
Garry R. Osgood
Christian Rauch