February 12, 2021, 16:50 (GMT) |
Merge branch 'blender-v2.92-release' |
February 12, 2021, 16:44 (GMT) |
Fix T84899: instance ids are not unique in common cases Ids stored in the `id` attribute cannot be assumed to be unique. While they might be unique in some cases, this is not something that can be guaranteed in general. For some use cases (e.g. generating "stable randomness" on points) uniqueness is not important. To support features like motion blur, unique ids are important though. This patch implements a simple algorithm that turns non-unique ids into unique ones. It might fail to do so under very unlikely circumstances, in which it returns non-unique ids instead of possibly going into an endless loop. Here are some requirements I set for the algorithm: * Ids that are unique already, must not be changed. * The same input should generate the same output. * Handle cases when all ids are different and when all ids are the same equally well (in expected linear time). * Small changes in the input id array should ideally only have a small impact on the output id array. The reported bug happened because cycles found multiple objects with the same id and thought that it was a single object that moved on every check. Differential Revision: https://developer.blender.org/D10402 |
February 12, 2021, 16:35 (GMT) |
Cycles: Remove split kernel This changes removes split kernel implementation and majority of related boiler plate code on device level. The goal is to free up some room for the new split kernel implementation. The OpenCL becomes unusable with this change. CPU, CUDA, and OptiX are still working. CPU still passes regression tests. There are some more possibilities to simplify code, like remove the requested features and CPUKernelFunctions abstraction, but it can happen as a followup development. |
February 12, 2021, 16:22 (GMT) |
Remove limitation of cubemap layers to be multiple of 6 |
February 12, 2021, 15:54 (GMT) |
Merge branch 'blender-v2.92-release' |
February 12, 2021, 15:54 (GMT) |
GPencil: Fix compiler warnings after previous commit These warnings were not detected by Windows compiler as the Linux compiler does. |
February 12, 2021, 15:16 (GMT) |
Fix Unused var |
February 12, 2021, 15:16 (GMT) |
Fix errors and warnings |
February 12, 2021, 15:16 (GMT) |
Fix errors when binding framebuffer or offscreen (and Cleanup) |
February 12, 2021, 15:16 (GMT) |
GPUTexture(width, height, depth, is_layered=False, is_cubemap=False, format='RGBA8', data=None) |
February 12, 2021, 15:16 (GMT) |
GPUFrameBuffer: Rename 'tex_' to 'color_' |
February 12, 2021, 15:16 (GMT) |
Transform the 'viewport' getsetter of the 'GPUFrameBuffer' into 'viewport_get' and 'viewport_set' methods |
February 12, 2021, 15:16 (GMT) |
Rename documentation 'width, height' to 'sizex, sizey' |
February 12, 2021, 15:14 (GMT) |
February 12, 2021, 15:14 (GMT) |
Baking: support vertex color baking of normal material, UV discontinuities Baking vertex colors per-corner leads to unwanted discontinuities when there is sampling noise, for example in ambient occlusion or with a bevel shader node for normals. For this reason the code used to always average results per-vertex. However when using split normals, multiple materials or UV islands, we do want to preserve discontinuities. So now bake per corner, but make sure the sampling seed is shared for vertices. Fix T85550: vertex color baking crash with split normals, Ref D10399 Fix T84663: vertex color baking blending at UV seams |
February 12, 2021, 15:14 (GMT) |
CMake/Deps: fix build of nasm when asciidoc and xmlto are unavailable Create zero-byte manual page files `nasm.1` and `ndisasm.1` such that nasm's `make install` step succeeds. Installing nasm requires that its manual pages are built. This requires local packages `asciidoc` and `xmlto` to be installed. Not only does `asciidoc` pull in 110 MB of packages (itself + dependencies), there is also no need for these manual pages. Nasm is just used for building other dependencies, and not even part of our precompiled libraries in SVN. Reviewed By: sebbas Differential Revision: https://developer.blender.org/D10396 |
February 12, 2021, 15:14 (GMT) |
Fix T85558: crash changing the resolution mode of the "volume to mesh" node The nodes update function geo_node_volume_to_mesh_update would not run if it is not the very first node in the tree. If the update function is not run, there are sockets not cleared from the SOCK_UNAVAIL flag (but this needs to be done -- these get available depending on the chosen mode). Havent tracked down why this was actually updating when it was the first node in the tree, but now make sure we always get an update by specifing an appropriate RNA update callback for the property. Maniphest Tasks: T85558 Differential Revision: https://developer.blender.org/D10403 |
February 12, 2021, 15:14 (GMT) |
Geometry Nodes: remove incorrect assert It is perfectly valid that an attribute does not exist and cannot be created. For example, this can happen when a mesh does not contain any vertices. |
February 12, 2021, 15:13 (GMT) |
Fix T85545: changing position attribute does not tag normals dirty This makes it so that normals are tagged dirty whenever the position attribute is requested for writing. This seems like a good default. If the calling code is aware of normals, it could untag normals when they are not changed by the operation. Differential Revision: https://developer.blender.org/D10397 |
February 12, 2021, 15:13 (GMT) |
Fix T79999: Double color management applied during viewport animation render In 2.81 there was a change to increase the performance of viewport animation rendering. This change would perform the color management on the GPU if the only 8bit was needed. This saved CPU cycles and data transfer. The issue is that in the image editor or when saving the image the CM will be reapplied. Although the speed is desired, exporting the actual colors has more priority. In the ticket there is an analysis that shows that shows that this fix is the correct short term step to take. It would be better that the render result is aware of the color space of its buffers so the applying color management could be skipped when saving to disk or drawing in the image editor. The issue with this change is the performance penalty it has. Reviewed By: Brecht van Lommel Maniphest Tasks: T79999 Differential Revision: https://developer.blender.org/D10371 |
|
|
|


Master Commits
MiikaH:n Sivut a.k.a. MiikaHweb | 2003-2021