english Sivu saatavilla vain englanninkielisenä.

Blender Git Statistics -> Developers -> Alaska

Alaska (Alaska)

Total Commits : 6
Master Commits : 3
Branch Commits : 3
First Commit : August 20, 2021
Latest Commit : November 25, 2021

Commits by Month

DateNumber of Commits
November, 20211
October, 20211
September, 20212
August, 20212

Commit Distribution

PathNumber of Commits
cycles-x3
master3

Favourite Files

FilenameTotal Edits
render_scheduler.cpp2
render_scheduler.h2
tile.cpp1
tile.h1
work_tile_scheduler.h1
integrator_tile_test.cpp1
ui.py1
work_stealing.h1
properties.py1
integrator.cpp1

File Changes

ActionTotalPer Commit
Modified142.3

Code Changes

ActionTotalPer Commit
Lines Added10517.5
Lines Removed7212.0

Latest commits Feed

Revision b41c72b by Alaska / William Leeson (master)
November 25, 2021, 08:32 (GMT)
Fix performance decrease with Scrambling Distance on

With the current code in master, scrambling distance is enabled on non-hardware accelerated ray tracing devices see a measurable performance decrease when compared scrambling distance on vs off. From testing, this performance decrease comes from the large tile sizes scheduled in `tile.cpp`.

This patch attempts to address the performance decrease by using different algorithms to calculate the tile size for devices with hardware accelerated ray traversal and devices without. Large tile sizes for hardware accelerated devices and small tile sizes for others.

Most of this code is based on proposals from @brecht and @leesonw

Reviewed By: brecht, leesonw

Differential Revision: https://developer.blender.org/D13042
Revision 9740027 by Alaska / William Leeson (master)
October 27, 2021, 13:58 (GMT)
Cycles: Update UI for Scrambling Distance Patch

The current UI for the Scramble Distance patch is grayed out
depending on different settings that are enabled. However it
didn't make much sense to me so I have updated when the UI is
grayed out to hopefully make more sense to the end user.

Differential Revision: https://developer.blender.org/D12963
Revision c010abd by Alaska / Brecht Van Lommel (cycles-x)
September 20, 2021, 12:40 (GMT)
Fix incorrect auto minimum samples for adaptive sampling

The comment did not match the implementation.

Differential Revision: https://developer.blender.org/D12561
Revision 58011ab by Alaska / William Leeson (cycles-x)
September 3, 2021, 11:32 (GMT)
Cycles-X: Fix incorrect performance calculation at certain navigation resolutions

During viewport navigation the algorithm that calculates the resolution divider assumes that the at every resolution division the sample count will be 4. This is not true for cases where the resolution division is equal to `2 * pixel_size` and `pixel_size`. In those cases the sample count is 1. As a result the algorithm assumes `2 * pixel_size` and `pixel_size` are too expensive in a lot of cases and thus doesn't use it.

This patch addresses this issue by informing the algorithm of changes in sample counts between resolution divisions meaning it can more properly gauge the performance of various resolution divisions. As a result the algorithm is more likely to pick the correct resolution divider when performance of the scene is in the range that `2 * pixel_size` and `pixel_size` are viable options all while keeping the performance target at 30fps like before.

Along with this patch the sample count while the resolution divider is equal to `2 * pixel_size` has been increased from 1 sample per pixel to 2 samples per pixel. Without an increase to this value there are some negative side effects. I have chosen the value of 2 and not 4 because this values means at a resolution divider of `2 * pixel_size` the rendering is still cheaper than a resolution divider of `pixel_size`.

Differential Revision: https://developer.blender.org/D12367
Revision 60030d1 by Alaska / William Leeson (cycles-x)
August 30, 2021, 07:20 (GMT)
Cycles-X: Change viewport update system to be time based rather than sample based on fast devices

The viewport update speed when rendering with infinite samples has been changed to work based primarily on time since render start rather than sample count.

This change has been made because if you have a device fast enough to exceed 32 samples in 0.1 seconds, then the next viewport update you'll observe is 2 seconds after `render start` which can be annoying for anyone wishing to quickly iterate on fine details as `render start` is usually a 1 sample per pixel image meaning fine detail is lost in noise or overly blurred by a denoiser.

This change was made possible with help from Will Rusthon (a friend) and Blender developers.

Here is an example video of the issue (some of the "viewport changes" you see are due to compression artifacts to keep the video small):
{F10290321}

And here is my fix tested (the second demo with the caustics is there to show that the viewport updates reduce as time goes on. It's easier to see in the caustics scene due to the fireflies. This is important because reduced viewpoint updates means faster ray tracing. The difference is that with this patch the slow viewport update (once every 2 seconds) has been moved to after rendering for 8 seconds rather than occurring at 32 samples which could happen really quickly with simplistic scenes. Also the denoiser stopping at the end of the video has been fixed and is currently in the patch available for review):
{F10290508}

Reviewed By: sergey, leesonw

Differential Revision: https://developer.blender.org/D12265
Revision cd8d938 by Alaska / Brecht Van Lommel (master)
August 20, 2021, 15:43 (GMT)
Fix T90804: small grammatical error in noise threshold description

Differential Revision: https://developer.blender.org/D12277

MiikaHweb - Blender Git Statistics v1.06
Tehnyt: Miika HämäläinenViimeksi p?ivitetty: 07.11.2014 14:18 MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021