March 19, 2021, 01:11 (GMT) |
LineArt: Binary weights option. |
March 19, 2021, 01:01 (GMT) |
LineArt: Remove geometry space chaining and clean up vertex group selection code. |
Revision 64ee9ed by Bastien Montagne March 18, 2021, 21:14 (GMT) |
Initial raw liboverride-dedicated view in the Outliner. Disclaimer: this is merely a copy of the Libraries (aka blend file) view, with some minor tweaking. |
Revision 40ed613 by Julian Eisel (asset-browser, asset-browser-poselib, asset-system-filelist, temp-pose-flipping-fix-attempt, ui-asset-view-template) March 18, 2021, 18:47 (GMT) |
Cleanup: First round of polishing (C++ style, type safety, naming, etc) * Follow "rule of five" * Explicit conversion constructors * Separate inteface declarations from definitions (readability) * Avoid clang-tidy error * Naming .... |
March 18, 2021, 18:01 (GMT) |
Fix crash rendering scene without light |
March 18, 2021, 18:01 (GMT) |
Fix OpenImageDenoise link error |
March 18, 2021, 17:30 (GMT) |
EEVEE: Add simplify fill option for shadows |
March 18, 2021, 17:15 (GMT) |
Fix Cycles viewport flicker after recent refactor Was a mistake in the modification check of the GPU display parameters. |
March 18, 2021, 16:58 (GMT) |
Cycles: Fix possible missing updates in PathTrace The path tracer schedules multiple samples to render to keep device busy between updates. This was causing an issue with a time check in the update function: it is possible that N samples finished rendering slightly faster than aimed 1 second, so the update callback will not be called. So perceptually rendering was looking sluggish in some scenes, especially at the lower number of samples rendered. Now the frequency of updates is fully under PathTrace::render_samples control. Technically, simple scenes might be rendering slower now, since there will be more updates now. This could be addressed by aiming for a longer render times between updates (schedule more samples to the device) after reaching certain noise level. |
March 18, 2021, 16:33 (GMT) |
Cycles: Initial implementation of GPUDisplay The idea of GPUDisplay is to take care of viewport texture update and drawing in a way that is the same exact from API point of view for both CPU and GPU rendering. This change moves a lot of code and refactors it in a more reusable and isolated building blocks to implement the GPUDIsplay for Blender viewport. The CPU rendering is same exact from users perspective. The GPU rendering currently does not use CUDA OpenGL buffers, which can potentially cause degradation in the performance. There is also a temporary half buffer in BlenderGPUDisplay, because it is not clear yet how to create OpenGL context, so that we can update texture from different thread than the drawing. The update of the GPUDisplay is performed by the Session. Ideally, this will be done in PathTracer so that it can avoid unnecessary updates if sample rendered quick enough. This behavior will need a bit deeper change in a way how TIleManager, Session::render() and PathTracer are communicating to each other. |
March 18, 2021, 16:33 (GMT) |
Cycles: Remove duplicated code This was a leftover from run_cpu() times which was doing an explicit reset before main loop iteration. Now this is all handled at the top of the main render loop in run_update_for_next_iteration(). Should be no functional changes. |
March 18, 2021, 16:33 (GMT) |
Cycles: Remove unused update time tracking |
March 18, 2021, 16:33 (GMT) |
Cycles: Fix possible stalling in viewport updates If rendering a sample takes longer than update timeout it was possible to have viewport navigation which will never update a viewport during navigation. For example, rendering on CPU with high start resolution and denoising enabled could have taken a bit more than configured 0.1sec. Before this change the viewport would have only updated after navigation was finished. After this change the viewport will be refreshed at about 10fps, which is better for artists. |
March 18, 2021, 16:33 (GMT) |
Cycles: Remove unused reset time tracking |
March 18, 2021, 16:33 (GMT) |
Cycles: Fix crash when rendering with OSL enabled Implement move semantic for the CPUKernelThreadGlobals. Without this the way how kernels globals were initialized was using move semantic, but was leaving runtime pointers in original and a moved copy. |
March 18, 2021, 16:33 (GMT) |
Cycles: Fix usage of emplace_back() |
March 18, 2021, 16:33 (GMT) |
Cycles: Remove kernel status from Progress Was a remaining part from feature kernels. The kernel status was never called now, meaning, all the places which were using that status were using an empty string, effectively ignoring it. |
March 18, 2021, 16:33 (GMT) |
Cycles: Log render time from main rendering loop This way it is possible to log render time of viewport. Ideally would need to also be possible to expose it into the interface so that artists can use it for benchmarking as well, but that would be a more intrusive change. |
March 18, 2021, 16:33 (GMT) |
Cycles: Hide more logic from main render loop No functional changes, just moving decision making logic to a more consolidated place. |
March 18, 2021, 16:26 (GMT) |
Merge branch 'master' into eevee-gpencil |
|
|
|


Master Commits
MiikaHweb | 2003-2021