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.
While atomics library was trying to use "user-space" defined
LIKELY() and UNLIKELY(), this is not always true that user
code was checking for those macro coming from an unrelated
area.
This commit adds a sample-based profiler that runs during CPU rendering and collects statistics on time spent in different parts of the kernel (ray intersection, shader evaluation etc.) as well as time spent per material and object.
The results are currently not exposed in the user interface or per Python yet, to see the stats on the console pass the "--cycles-print-stats" argument to Cycles (e.g. "./blender -- --cycles-print-stats").
Unfortunately, there is no clear way to extend this functionality to CUDA or OpenCL, so it is CPU-only for now.
Reviewers: brecht, sergey, swerner
Reviewed By: brecht, swerner
Differential Revision: https://developer.blender.org/D3892
Meshes from evaluated objects may already have modifiers applied, but
that's not the case for curves, we need to do that when converting them
to meshes.
In some instances, the number of control vertices of a hair could change mid-frame.
Cycles would then be unable to calculate proper motion blur for those hairs. This adds
interpolated CVs to fill in for the missing data. While this will not necessarily result in
a fully accurate reconstruction of the guide hair, it preserves motion blur instead of disabling it.
Reviewers: #cycles, sergey
Reviewed By: #cycles, sergey
Subscribers: sergey, brecht, #cycles
Tags: #cycles
Differential Revision: https://developer.blender.org/D3695
For some reason when building with gcc-7.2 (which is default
in previous Ubuntu LTS) the guarded allocator is not being
properly instantiated.
Doesn't happen with newer version of gcc-7 which is 7.3, and
also doesn't happen with gcc-6 and gcc-8.
Would be nice to know what is wrong, but for the time being
committing workaround which keeps Blender users happy.
While we shouldn't have logic in an entry point, and since one should
not be making typos when moving lines around, there is bigger entanglement
issue with BVH host code using kernel function. This is bad violation,
but is tricky to get solved moments before the weekly.
In order to keep things in a (less) broken state than before own cleanup
reverting the changes.
This reverts commit 2bad10be96.
This reverts commit ddabb21d05
Currently this is possible after built-in images are loaded in memory.
Allows to save memory used by dependency graph and copy-on-write.
In practice this lowers peak system memory usage from 52GB to 42GB on
a production file of spring 03_035_A.lighting.
Note, that this only applies to F12 and command line renders.
Bigger note, that this optimization is currently only possible if
there are no grease pencil objects to be rendered.
Now it shows more compact info below the view/object name. Render time and
memory usage is left out, as in most cases this is not so important. These
could be added back optionally if needed.
Note that this is turned off by default and must be enabled at build time with the CMake WITH_CYCLES_EMBREE flag.
Embree must be built as a static library with ray masking turned on, the `make deps` scripts have been updated accordingly.
There, Embree is off by default too and must be enabled with the WITH_EMBREE flag.
Using Embree allows for much faster rendering of deformation motion blur while reducing the memory footprint.
TODO: GPU implementation, deduplication of data, leveraging more of Embrees features (e.g. tessellation cache).
Differential Revision: https://developer.blender.org/D3682
It mainly contains properties that affect the final render/viewport and it's handy
to see if it's enabled or not while going through the render settings.
Only affects internal API, bout could be exposed as an option for
the compatibility reasons with other software.
Is a part of some ongoing development of multires, but might or
might not be used.
Mainly useful for debugging. Previously, when AVX2 was disabled
in the debug panel but BVH layout was kept on BVH8 nothing was
rendered.
Needed to make it so supported BVH layout mask for devices is
queried in "dynamic", so it is possible to use DebugFlags there.
Needed for the animation denoiser since the denoising filter is done separately there.
Reviewers: brecht, sergey
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D3833
Brecht Van Lommel
Sybren A. Stüvel
Campbell Barton
Robert Guetzkow
Dalai Felinto
Philipp Oeser
Sergey Sharybin
Stefan Werner
Lukas Stockner
Christopher Peerman
Alex Fuller
Jacques Lucke
Severin
Bastien Montagne
Lucas Boutrot
Clément Foucault
Gaia Clary
Niels
Shane Ambler
Antony Ryakiotakis
Jens Verwiebe
Pablo Vazquez
William Reynish