September 17, 2021, 09:34 (GMT) |
Add transform tools to sequencer & preview mode |
September 17, 2021, 09:23 (GMT) |
Cleanup: Unused vars |
September 17, 2021, 09:18 (GMT) |
Cycles X: Real memory saving when using tiled rendering The general idea is to delay reading EXR files for until after all view layers are rendered. Once they are all rendered, BlenderSession frees up as much memory as possible, and initiates processing of the on-disk files. The processing includes reading the file, optional denoising of the full frame (if the denoising is enabled), and writing the result via the write callback. The processing is done as a state-machine which routes specific calls to a full-frame processing, which allows to re-use same tile write callback in the software integration. In order to be able to know which view layer and render view is being written the API has been extended to write layer and view names. Done via BufferParams, as layer and view concepts are quite typical for the EXR files. The BufferParams also contains all fields needed for buffers access outside of the scene graph. Differential Revision: https://developer.blender.org/D12503 |
September 17, 2021, 09:11 (GMT) |
Fix incorrect origin for gizmo with multi-selection |
September 17, 2021, 08:56 (GMT) |
Merge branch 'master' into temp-field-visualization |
September 17, 2021, 08:56 (GMT) |
Fix wrong display when rendering multiple view layers in Cycles X The issue was that the texture used by GPUDisplay was never cleared and was only used for partial updates. The actual reasoning of that is a bit more tricky than it looks on a first glance since the GPUDisplay was re-created together with session via session_reset so one would think it is weird to have a texture from previous view layer to appear in the new GPUDisplay. Probably caused by the fact that OpenGL is the same for all view layers, and texture ID is happened to be the same. Anyhow, the way texture is created is considered to have an undefined behavior by the standard when is attempted to be used without explicit data assignment. This change makes it so new texture is always guaranteed to be zeroed and that the GPU display is cleared when rendering multiple views from within the same session. The clearing is done by a GPUDisplay subclass, as the parent does not know details of how to perform the zeroing. For the CPU the zeroing is done on a mapped memory, as it makes it easy and does not require any extra OpenGL requirements. For the graphics interop things a bit more difficult as attempts to map texture will make graphics interop to fail out (it really wants to be an exclusive thing which takes care of the memory mapping). So for the graphics interop clearing is done when memory is mapped by the interop implementation. Differential Revision: https://developer.blender.org/D12514 |
September 17, 2021, 08:38 (GMT) |
Fix persistent data not allowing to change sample count and time limit The root cause was that `session->params` were never updated to the new parameters. Made it so `session->reset()` will make sure the session is fully up to date with the desired parameters. Investigation by @dingto, code by self. Differential Revision: https://developer.blender.org/D12515 |
September 17, 2021, 08:25 (GMT) |
Fix pass accessor with 0 samples Avoid division by zero when calculating scale, and avoid multiplication by inf later on. The pixel processing functions are changed so that they return fully transparent pixel for pixels where number of samples is 0. This allows to have matched behavior of non-finished tiles with master, without relying on non-finite math. The extra condition when calculating scale is inevitable, and hopefully the pixel processing function's if statement gets folded into it as well ()due to force-inline). Differential Revision: https://developer.blender.org/D12518 |
September 17, 2021, 08:14 (GMT) |
Fix race condition between draw and render threads Caused crashes like the one William was fixing in the D12498, or the crash when rendering multiple view layers. Need to guarantee that the render engine is not freed during drawing, and that the external engine is not in the middle of re-allocation due to `update()` which might cause session reset (happens in Cycles). Had to introduce a separate lock. The reason for this comes from the fact that we need to acquire the engine early on in the draw manager, and release it only when drawing is done. However, some other engines (like overlay) might be requesting ImBuf for the image space, so that they know dimensions. Such acquisition is guarded by the resultmutex. This means reusing `resultmutex` for the `RenderEngine::draw()` would cause a recursive lock. Not entirely happy with implicit release in the external engine code, but not sure there is an existing way of making it explicit without introducing new draw engine callback. Differential Revision: https://developer.blender.org/D12521 |
September 17, 2021, 08:04 (GMT) |
Remove commented out code |
September 17, 2021, 08:03 (GMT) |
Fix mirror X/Y not being taken into consideration. |
September 17, 2021, 05:38 (GMT) |
Fix memleak |
September 17, 2021, 03:32 (GMT) |
Fix "guaranteed" images not loading. Add `SEQ_FLAG_SKIP_THUMBNAILS` flag to signify that strip did not produce thumbnail and so should be skipped when drawing. |
September 17, 2021, 03:29 (GMT) |
Sculpt dyntopo: Roughed out skeleton of new brush engine API Command Lists * The new system will be based on command lists generated by (eventually) a node editor. * For now, the lists will be hardcoded. * Idea is to make a minimal viable brush engine that won't cause file breakage when the upgrade to node-based brushes happen. Brush Channels * Wrote new structures and API to wrange brush parameters: BrushChannel. * Supports, floats, ints, enums, bitmasks, with plans for vec3 and vec4. * This will replace UnifiedPaintStruct, most of the members of Brush and the DynTopoSettings struct. * Brush channels can be mapped to various input device channels (e.g. pen pressure); each mapping has its own associated curve (CurveMapping instance) and bounds. Brush channel inheritence chaining * Brush channels can form inheritence chains * Channel sets are stored in three places: in the scene toolsettings, in Brush, and in individual brush commands. * Node groups will also have a channel set. * Channels in each set can be flagged to inherit from the parent set. * Inheritence happens in seperate merged channel sets at runtime. The final Brush channels live in Brush->channels_final, while the final command channels live in BrushCommand->params_final. |
September 16, 2021, 20:44 (GMT) |
Merge branch 'master' into temp_bmesh_multires |
September 16, 2021, 19:20 (GMT) |
Fix T91426: don't display outdated denoised result when increasing samples |
September 16, 2021, 18:33 (GMT) |
Fix T91427: wrong display with adaptive sampling and pixel size Need to use the appropriate resolution divider for postprocessing of such renders. |
September 16, 2021, 17:58 (GMT) |
Fix static initialization order crash with denoise parameters Now that DenoiseParams is a Node, we can no longer create an instance of it when defining the Integrator Node, since that might not have been registered yet. |
September 16, 2021, 17:42 (GMT) |
commit prior to merge |
September 16, 2021, 17:39 (GMT) |
Fix T91441: bump node not working for shadow rays |
|
|
|


Master Commits
MiikaHweb | 2003-2021