| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
3D image dimensions should be updated on the Cycles side before loading
the smoke data.
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
|
|
|
|
When using `--cycles-resumable-num-chunks N` to render a subset of the
samples, having N close to the total number of samples causes rounding
issues.
For example, a file configured for 250 samples and 150 chunks should
have 1.6666 sample per chunk. The old code rounded this to 2 samples per
chunk, which would result in too many samples being rendered. When
rendering a single chunk this doesn't matter much, but when larger chunk
ranges are rendered with `--cycles-resumable-start-chunk` and
`--cycles-resumable-end-chunk` the rounding errors start to add up.
By multiplying with the number of chunks to render first, and only round
to integers after that, this issue is solved. In the above example,
rendering 3 chunks will correctly render 5 samples rather than 6.
When the requested number of chunks is larger than the number of samples
there will be duplicate samples (that is, sample N appearing both in
chunk M and M+1). In this case a warning is printed to stderr.
This is needed for T50977 Progressive render: use non-uniform sample
chunks.
Reviewed by: sergey
Differential Revision: https://developer.blender.org/D4282
|
|
We've had many reported crashes on Windows where we suspect there is a
corrupted OpenCL driver. The purpose here is to keep Blender generally
usable in such cases.
Now it always shows None / CUDA / OpenCL in the preferences, and only when
selecting one will it reveal if there are any GPUs available. This should
avoid crashes when opening the preferences or on startup.
Differential Revision: https://developer.blender.org/D4265
|
|
|
|
Convention is to only have public domain code templates. Also fixes wrong
license header in Cycles.
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D4258
|
|
|
|
This is a quick workaround to prevent the crashes with multi-view.
The ultimate solution can be plenty, and would turn around refactoring
Cycles to handle multi-view internally, so that depsgraph could be freed
before render with no problems.
Reviewers: brecht, sergey
For the complete discussion check: https://developer.blender.org/D4239
|
|
|
|
The integrator maximum number of closures was not set properly for the CPU/mega
kernels to match the actual available memory. Before relatively recent code
refactoring we did not use this value in those kernels so it worked fine.
|
|
this can now be found in the sidebar View panel
- uses existing 'lock_camera_and_layers' but renames the property to
'use_local_camera'
- uses RNA_def_property_boolean_negative_sdna to flip the value
- remove the local view code in
rna_SpaceView3D_lock_camera_and_layers_set
- update Python code
- update Addons code will be separate commit
Fixes T60756
Reviewers: billreynish, brecht
Maniphest Tasks: T60756
Differential Revision: https://developer.blender.org/D4247
|
|
|
|
Even though it makes sense logically to have displacement actually displace
the mesh, this is causing a lot of confusion for existing users that are used
to the previous behavior. Further, since Eevee does not support displacement
yet and the discrepancy between the viewport and final render is problematic.
|
|
|
|
|
|
|
|
Prevents clang-format merging into a single line.
|
|
|
|
|
|
|
|
Refactors Cycles mesh export a bit to avoid unnecessary copies and to be in
sync with the Blender baker.
|
|
Cryptomatte on CPU with accurate mode was hitting uninitialized variables.
This is now explicitly initializing them to NULL.
|
|
|
|
|
|
|
|
|
|
|
|
Differential Revision: https://developer.blender.org/D4173
|
|
Differential Revision: https://developer.blender.org/D4174
|
|
|
|
|
|
|
|
This change brings back old original logic which was checking
whether worker threads do fit into an active CPU group. But
it does it a bit smarter now and is also checking affinity
within that group. This way Cycles will use all threads on a
Threadripper2 CPU if it's set to automatic number of threads,
but on another hand will not change affinity if user requested
16 threads and changed Blender affinity.
|
|
|
|
Tweaked scheduling so it survives this situation by scattering
"extra" threads uniformly over all the NUMA nodes.
There are still tweaks possible to make some specific hardware
configurations work better.
|
|
|
|
|
|
In some cases it would load adaptive kernels or even start rendering
twice because the first time the scene was not fully synced yet.
|
|
|
|
|
|
|
