I considered just copying the evaluated data from the LayerCollection.
However we need to run the evaluation so Depsgraph can handle overrides.
I will double-check with Sergey Sharybin.
We need to traverse the same exact objects for both nodes and relationship
builder. We were using FOREACH_SCENE_OBJECT for relationships, which
would lead to plenty of warnings in multiple situations.
In the future we will need to change this to build the depsgraph
relations and nodes to one single render_layer.
Fix T51780: If an object is in two collections and I do a full copy of
scene things go bad
Now, when there is no usable neighboring pixel for denoising, the noisy value
is preserved instead of producing a NaN.
Also, negative results are clamped to zero.
Note that there are just workarounds that don't fix the underlying problems,
but these issues are very rare and I'm not sure if it's even possible to fix
the underlying problems without introducing a significant slowdown or quality
decrease in other situations.
Because of that and since 2.79 is happening very soon, I just went for these
workarounds for now.
Replaces the placeholder 'emtpy' icons of "Force Field" and "Group
Instance" entries in object-add menu with proper new ones.
Icons by @zlsa, thanks a lot!
Maniphest task T51291.
Technically not passing all buffers used by a kernel is undefined
behavior. We haven't had any issues with this so far on AMD or
Nvidia, but it's known to be a problem with Intel and we received
a report from AMD that this is a problem on newer hardware, so we
need to make this change at some point.
Unfortunately there a cost to being correct, about 5% for the
benchmark scenes. For low sample counts it's even worse, I've
seen up to 50% slowdown. For the latter case I think adjusting
tile updating logic can help, but not sure what that would look
like yet (it would be just a few lines change however).
Unlike regular path tracing, branched path tracing is usually used with lower
sample counts, at least for primary rays. This means that are less samples for
the GPU to work on in parallel and rendering is slower. As there is less work
overall there is also more inactive threads during rendering with BPT. This
patch makes use of those inactive rays to render branched samples in parallel
with other samples.
Each thread that is preparing for a branched sample will attempt to find an
inactive thread and if one is found the state for the sample is copied to that
thread. Potentially, if there are enough inactive threads, 100s of branched
samples could be generated from the same originating thread and ran in
parallel giving large speed ups.
Gives 70% faster render for pavillion midday scene. 20-60% faster on BMW
with car paint replaced with SSS/volumes.
Due to various driver issues with AMD GCN 1 cards we can no longer support
these GPUs. This patch makes them unavailable to select for Cycles rendering.
GCN cards 2 and higher are still supported. Please use the most recent
drivers available to ensure proper functionality.
See here for a list to check which GPUs are supported:
https://en.wikipedia.org/wiki/List_of_AMD_graphics_processing_units
Sync with custom-manipulators branch
- Use identifiers for properties.
- Property array index access.
- Remove operator from manipulators
(wasn't used and will likely add in a different way).
One 1024px² octahedral probe (according to the GPU mem stats):
- RGBA16F = 17Mb
- RGB_11_11_10 = 4Mb
For the time being I prefer to maximize the number of probe possible in the scene for users to test.
This is obviously a temporary solution and the final choice of cubemap format should be exposed to the user.
After using it for like 30 sec, the min max bound box is absolutely not practical. Reverting into using a unit cube with object transform.
This also simplify the code.
In the future of center probes will be implemented using another object matrix (via an object pointer).
Probes were completely out of depsgraph, so tagging them could not work at all.
For now using some placeholder operations just to ensure order of updates.
We still do it a few times, but that helps already. Related to T51718.
Note that it also reinforces the idea that any geometry datablock will
have a generated copy-on-write Mesh provided by Depsgraph.
