Age | Commit message (Collapse) | Author |
|
Before, Cycles was using a shared Embree device across all instances.
This could result in crashes when viewport rendering and material
preview were using Cycles simultaneously.
Fixes issue T80042
Maniphest Tasks: T80042
Differential Revision: https://developer.blender.org/D8772
|
|
In scenes such as Cosmos Laundromat, there were memory allocations bigger than
2GB which would overflow.
Problem and solution found by AMD, thanks!
|
|
|
|
We forgot to update this code as part of D3108. I'd like to include this in 2.90,
it's entirely broken now so can't really get any worse.
Differential Revision: https://developer.blender.org/D8738
|
|
The previous fix loaded the pixels so existing tiles were not overwritten.
However the Cycles render buffer is expected to be scaled by the number of
sample, which was not taken into account.
This is not ideal in that previews could have a mismatched number of samples
between multiple objects, though the result will be correct. The better solution
would be to bake all objects together per tile, rather than one after the other.
But that is a bigger change than we can do in 2.90.
Differential Revision: https://developer.blender.org/D8704
|
|
The return value of scene_intersect must be checked, the isect struct members
can't be assumed to be initialized if that returns false.
Differential Revision: https://developer.blender.org/D8692
|
|
For 2.90 release this should not be exposed in the RNA API.
In master this needs to be ON by default, that's all.
Differential Revision: https://developer.blender.org/D8589
|
|
specified
Maniphest Tasks: T77683
Differential Revision: https://developer.blender.org/D8593
|
|
Embree's occlusion filter was checking against the wrong object ID
and not exiting correctly in case of a mismatch.
Fixes T79723
|
|
Clamp to a minimum angle to avoid precision issues.
|
|
Refitting the BVH does not work in this case, it needs to be fully rebuilt.
|
|
|
|
The previous algorithm was not using all of the requested grids to build a mesh
around the volume due to limitations regarding the use of a dense buffer to
gather information about the volume's topology. This resulted in artefacts during
rendering.
The mesh generation is now done by merging all of the input grids and using the
resulting grid's topology to create the mesh. The generation of the mesh
is still done in index space as before, and the vertices are converted to object
space by using the merged topology grid indexToWorld transform.
To be able to merge the grids together we have to make sure that their transformation
matrices and their index spaces match, thus, if they do not match we simply resample
the grids. This behaviour should tackle one other limitation of the current algorithm,
which is that only one transformation matrix was used to generate the final mesh.
If we do not have an OpenVDB grid for the requested volume data, we generate
a temporary OpenVDB grid for it.
Differential Revision: https://developer.blender.org/D8401
|
|
|
|
In an upcoming bugfix we'll use OpenVDB data structures directly to build mesh
for sparse OpenVDB volumes, loading them OpenVDB grids earlier and removing any
references to Blender data structures makes that easier.
This also makes changes to Blender volumes to support this, so Cycles can take
ownership of a grid without Blender having to keep its own reference to it.
This should also be useful in a future Python API.
Ref D8401
|
|
Optimization was disabled in this function to work around a bug in MSVC, use
a different solution that does not come with such a big performance regression.
|
|
|
|
The decomposed transform would have consists of nan values if the input
transform had zero scale.
Now the decomposition will check for zero scale, and if it is detected
then the result will be ensured to be finite. Additionally, rotation
value will be copied from previous/next time step to help avoiding
obscure interpolation.
The latter step can become more comprehensive than the current simple
implementation.
Differential Revision: https://developer.blender.org/D8450
|
|
Currently unused, preparing for an upcoming development.
|
|
Caused by c7aa0f9d743ee9cafe91b4a51d9f1ecc5e437d71.
Since above commit, BKE_image_user_frame_calc requires an image (not
just the iuser) to get the framenumber.
Cycles used to call this with NULL image (in `image_user_file_path` and
`image_user_frame_number`), now pass the image as well.
Maniphest Tasks: T79111
Differential Revision: https://developer.blender.org/D8439
|
|
|
|
|
|
The fisheye camera setup causes the edges of the image to not shoot primary rays. This was not
respected by OptiX because of an optimization that tried to reduce conditionals around trace calls.
Removing that does not seem to have an impact on performance anymore however and it fixes
the issue.
|
|
|
|
The OptiX kernels are compiled for target "compute_sm_52", which is only available on second
generation Maxwell GPUs, so disable support for older ones.
|
|
The sky will appear brighter than before by default. To compensate for this,
lower exposure in the Film panel. The default altitude was also changed from
90 to 15 degrees.
Patch contributed by Marco with the help of Ryan Jones.
Differential Revision: https://developer.blender.org/D8285
|
|
one is found
This patch changes the discovery of pre-compiled kernels, to look for any PTX, even if
it does not match the current architecture version exactly. It works because the driver can
JIT-compile PTX generated for architectures less than or equal to the current one.
This e.g. makes it possible to render on a new GPU architecture even if no pre-compiled
binary kernel was distributed for it as part of the Blender installation.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8332
|
|
|
|
|
|
|
|
Properly normalize buffers now. Also expose option to not use albedo and normal
just like OptiX.
|
|
Differential Revision: https://developer.blender.org/D8091
|
|
Differential Revision: https://developer.blender.org/D8091
|
|
Differential Revision: https://developer.blender.org/D8091
|
|
Differential Revision: https://developer.blender.org/D8091
|
|
For animation/driver purposes, being able to go outside of the 0-360
range makes things easier.
Differential Revision: https://developer.blender.org/D8091
|
|
|
|
This is not supported yet.
|
|
|
|
This was only visible when Cycles was enabled.
|
|
Performance is not great currently due to the API not seeming to support
efficient denoising of multiple tiles at the same time. So in many cases
only one or a few threads will actually be denoising at the same time.
In renders with many samples this is not a big problem, but for faster
renders it's a signficant overhead.
We should try to optimize this still, possibly by batching denoising of
a bigger neighborhood of multiple tiles at once.
|
|
|
|
|
|
Only run when there are volumes in the scene, and compute in parallel.
Ref T56939
Differential Revision: https://developer.blender.org/D8261
|
|
|
|
Problem identified by Milan Jaros.
|
|
I'm not sure if the Sky was deliberately left out or was just waiting for a
better moment, but so many I was disappointed that Sky in EEVEE is
completely white.
There are already 2 implementations (osl and gpu) so this is the third one.
Looking at other cases it seems that we are not supposed to share sources
between cycles and the rest? So the new util_sky_model files are just
copies of what is already in cycles, except that the data file uses the RGB
variant of the Hosek/Wilkie model, because we output RGB anyway (but can be
easily changed to XYZ if desired - the results are nearly identical).
I am not sure if it is okay to pass 3*9 float values as 3 mat4 uniforms (I
wanted to use mat3 but it does not work).
Also, should I cache the sky model data between renders if the parameters
do not change?
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D7108
|
|
Now transparent areas of the object will render objects behind.
Fixes T78728.
|
|
The spelling and capitalization of package name passed to find_package()
and find_package_handle_standard_args() needs to match.
Silences CMake warning about mismatch.
Differential Revision: https://developer.blender.org/D8247
|
|
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.
|