Previously, hair strands of zero length of too few control
points would have been ignored. This is fine for a render
without motion blur. But once motion blur is enabled it is
becoming more tricky to match topology.
Even more, it was causing access (and possibly writes) past
the array boundaries in case when time step 0 ignored some
strands and steps around it did not.
If this is becoming problematic for BVH to do reliable
intersections this is to be solved on the BVH builder side.
The export from Blender to Cycles shouldn't really make
decisions there.
All the controls were just really thrown in there without any proper
organization.
This gives it more structure.
- Correct use of sub-panels to communicate hierarchy and sections.
- Use flow layout for toggles.
- Use consistent names for "Bake Type".
The code assumed all datablocks were read from .blend files saved with the
same version. This restructures the Cycles versioning code to take into
account libraries.
This patch implements a workaround to get the multithreaded compilation from D2231 working.
So far, it only works for Blender, not for Cycles Standalone. Also, I have only tested the Linux codepath in the helper function.
Depends on D2231.
Patch by lukasstockner97, jbakker, brecht
job | scene_name | compilation_time
----------+-----------------+------------------
Baseline | empty | 22.73
D2264 | empty | 13.94
Baseline | bmw | 56.44
D2264 | bmw | 41.32
Baseline | fishycat | 59.50
D2264 | fishycat | 45.19
Baseline | barbershop | 212.28
D2264 | barbershop | 169.81
Baseline | victor | 67.51
D2264 | victor | 53.60
Baseline | classroom | 51.46
D2264 | classroom | 39.02
Baseline | koro | 62.48
D2264 | koro | 49.03
Baseline | pavillion | 54.37
D2264 | pavillion | 38.82
Baseline | splash279 | 47.43
D2264 | splash279 | 37.94
Baseline | volume_emission | 145.22
D2264 | volume_emission | 121.10
This patch reduced compilation time as the split kernels and base
kernels are compiled in parallel. In cycles debug mode (256) you can set
unmark the opencl single program file, what reduces the compilation time
even further (bmw 17 seconds, barbershop 53 seconds).
Reviewers: brecht, dingto, sergey, juicyfruit, lukasstockner97
Reviewed By: brecht
Subscribers: Loner, jbakker, candreacchio, 3dLuver, LazyDodo, bliblubli
Differential Revision: https://developer.blender.org/D2264
This patch implements a workaround to get the multithreaded compilation from D2231 working.
So far, it only works for Blender, not for Cycles Standalone. Also, I have only tested the Linux codepath in the helper function.
Depends on D2231.
Reviewers: brecht, dingto, sergey, juicyfruit, lukasstockner97
Reviewed By: brecht
Subscribers: Loner, jbakker, candreacchio, 3dLuver, LazyDodo, bliblubli
Differential Revision: https://developer.blender.org/D2264
Values outside the 0..1 range produce negative colors, so now clamp to that
range everywhere. Also fixes improper handling of hue > 2.0 in some places.
For OIIO 2.x we must use unique_ptr. This also required updating the
guarded allocator for std::move to work. Since C++11 construct/destroy
have a default implementation that also works this case, so we just
leave it out.
The render layer name is now always included. Best to keep these consistent,
so that animation denoising and sample merging works the same for both and
tests can be the same. Ref D4311.
This adds a cycles.denoise_animation operator, which denoises an animation
sequence or individual file. Renders must be saved as multilayer EXR files
with denoising data passes.
By default file path and frame range come from the current scene, and EXR
files are denoised in-place. Alternatively, a different input and/or output
file path can be provided.
Denoising settings come from the current view layer. Renders can be denoised
again with different settings, as the original noisy image is preserved along
with other passes and metadata.
There is no user interface yet for this feature, that comes later.
Code by Lukas with modifications by Brecht. This feature was originally
developed for Tangent Animation, thanks for the support!
Differential Revision: https://developer.blender.org/D3889
This adds a cycles.denoise_animation operator, which denoises an animation
sequence or individual file. Renders must be saved as multilayer EXR files
with denoising data passes.
By default file path and frame range come from the current scene, and EXR
files are denoised in-place. Alternatively, a different input and/or output
file path can be provided.
Denoising settings come from the current view layer. Renders can be denoised
again with different settings, as the original noisy image is preserved along
with other passes and metadata.
There is no user interface yet for this feature, that comes later.
Code by Lukas with modifications by Brecht. This feature was originally
developed for Tangent Animation, thanks for the support!
This is backporting a change from 2.8, which may help solve crashes when
activating a window. Previously bringTabletContextToFront() would call
tablet API functions with NULL tablet, which may crash on some drivers.
Ref T60811.
This is a request by the studio here to make it possible to see how
many samples were used to render a specific shot or a frame. It is a
bit more tricky than simply stamping number of samples from a scene
since rendering is happening in multiple ranges of samples.
This change makes it so Cycles saves configured number of samples for
the specific view layer, and also stores start sample and number of
samples when rendering only a subrange of all samples.
The format used is "cycles.<view_layer_name>.><field>", which allows
to have information about all layers in a multi-layer EXR file.
Ideally we can store simplified "cycles.<field>" if we know that there
is only one render layer in the file, but detecting this is somewhat
tricky since Cycles operates on an evaluated scene which always have
single view layer.
The metadata is shown in the Metadata panels for clip, image and
sequencer spaces.
Example screenshot which shows the metadata:
{F6527727}
Reviewers: brecht
Reviewed By: brecht
Subscribers: fsiddi
Differential Revision: https://developer.blender.org/D4311
This is the internal implementation, not available from the API or
interface yet. The algorithm takes into account past and future frames,
both to get more coherent animation and reduce noise.
Ref D3889.
Prefiltering of feature passes will happen during rendering, which can
then be used for denoising immediately or written as a render pass for
later (animation) denoising.
The number of denoising data passes written is reduced because of this,
leaving out the feature variance passes. The passes are now Normal,
Albedo, Depth, Shadowing, Variance and Intensity.
Ref D3889.
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
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.
This fixes following errors:
- The code didn't work correctly for edges reconstructed by
the OpenSubdiv's topology refiner (due to indexing
difference).
- Sharpness of non-manifold and boundary edges was not
working correctly.
Xorg's XIWarpPointer doesn't support multi-head display while
XWarpPointer does.
Revert since this is a known TODO in Xorg and setting a custom
xinput matrix seems not to be used often.
Resolves T50383
Xorg's XIWarpPointer doesn't support multi-head display while
XWarpPointer does.
Revert since this is a known TODO in Xorg and setting a custom
xinput matrix seems not to be used often.
Resolves T50383
Before this Blender always needed the Wintab driver. This adds support for the
native pressure API in Windows 8+, making it possible to get pressure sensitivity
on e.g. Microsoft Surface hardware without any extra drivers.
By default Blender will automatically use Wintab if available, and if not use
Windows Ink instead. There is also a new user preference to explicitly specify
which API to use if automatic detection fails.
Fixes T57869: no pressure sensitivity with Surface pen or laptop.
Code by Christopher Peerman with some tweaks by Brecht Van Lommel.
Differential Revision: https://developer.blender.org/D4165
This disables touch gesture recognition in Blender, avoiding any initial delay
when drawing with grease pencil, texture paint, etc.
Differential Revision: https://developer.blender.org/D4203
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.
(Part 1 was 00963afc14978b)
Does the following changes visible to users:
* Use panels and sub-panels for more structured & logical grouping
* Re-organized options more logically than before (see images in D4148)
* Use flow layout (single column by default).
* New layout uses horizontal margin if there's enough space.
* Change size of Preferences window to suit new layout.
* Move keymap related options from "Input" into own section.
* Own, left-bottom aligned region for Save Preferences button.
* Adjustments of names, tooltips & icons.
* Move buttons from header into the main region (except editor switch).
* Hide Preferences header when opened in temporary window.
* Use full area width for header.
* Don't use slider but regular number widget for UI scale.
* Gray out animation player path option if player isn't "Custom"
Internal changes:
* Rearrange RNA properties to match changed UI structure.
* Introduces new "EXECUTE" region type, see reasoning in D3982.
* Changes to panel layout and AZone code for dynamic panel region.
* Bumps subversion and does versioning for new regions.
RNA changes are documented in the release notes:
https://wiki.blender.org/wiki/Reference/Release_Notes/2.80/Python_API/Preferences_API
Design & implementation mostly done by @billreynish and myself.
I recommend checking out the screenshots posted by William:
https://developer.blender.org/D4148#93787
Reviewed By: brecht
Maniphest Tasks: T54115
Differential Revision: https://developer.blender.org/D4148
Please always build tests when messing with build system/libs, am tired
of fixing that kind of issues...
Also, that fix is probably not working for standalone, no idea where's
the numaapi lib then, but committing since I need a building blender
here (with the tests, yes).
Please always build tests when messing with build system/libs, am tired
of fixing that kind of issues...
Also, that fix is probably not working for standalone, no idea where's
the numaapi lib then, but committing since I need a building blender
here (with the tests, yes).
The issue was introduced by a Threadripper2 commit back in
ce927e15e0. This boils down to threads inheriting affinity
from the parent thread. It is a question how this slipped
through the review (we definitely run benchmark round).
Quick fix could have been to always set CPU group affinity
in Cycles, and it would work for Windows. On other platforms
we did not have CPU groups API finished.
Ended up making Cycles aware of NUMA topology, so now we
bound threads to a specific NUMA node. This required adding
an external dependency to Cycles, but made some code there
shorter.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Previously we would try to guess what the main tablet device is, but this is
error prone. Now we keep a list of X11 devices and try to match events to
them. On the Blender side there are still some limitations in regards to using
multiple devices at the same time, but this should improve things already.
Fixes T59645.
Object visibility is now handled by the depsgraph iterator, but this API
was incomplete as it made no distinction for visibility of the object itself,
particles and generated instances.
The depsgraph iterator API now includes information about which part of the
object is visible, and this is used by Cycles to replace the old custom logic.
Cycles and EEVEE visibility should now be consistent, which unfortunately does
means some subtle compatibility breakage for both.
Fixes T58956, T58202, T59284.
Differential Revision: https://developer.blender.org/D4109
The key indices were wrong: need to offset curve key index
by first curve key index. Also corrected calculation of the
interpolation step.
Annoyingly, can not reproduce this on a simple file, need
production rig. For the possible future look the following
file from Spring was used: 03_005_A.lighting.debug.blend
There are some changes in API of OpenImageIO, but those are quite
simple to keep working with older and newer library versions.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4064
It used to be used for some sort of ignoring automatically
generated bump nodes. But nowadays it causes one of the shaders
in Classroom demo file to be compiled wrong.
This is unfortunate, but the number of bugs in this configuration
keeps growing, and almost all of them are caused by bug in OpenCL
compiler.
The compiler is not likely to be fixed, since Apple declared OpenCL
deprecated.
This evil commit is aimed to keep officially supported features
of Blender in a good working and stable state.
The fix itself simply is to store the cage object as a pointer instead
of a string/name.
That said baking with or without cage is yielding very different results
than in 2.7.
This fixes our workaround for until proper solution is accepted
in upstream.
Now, when default view behaves same as it was supposed to (and
as it behaves in OCIO-1.0.9) it is obvious that our configuration
violates own design -- default view is used for cases when
images don't want to be displays using "render" settings.
This is something what is caused by OCIO library. The patch
has been submitted there:
https://github.com/imageworks/OpenColorIO/pull/638
For until it is refined and checked we do workaround from
our side.