Revision 7149cce by Brecht Van Lommel May 3, 2021, 20:10 (GMT) |
Fix T85287: Cycles deadlock loading Blender images in some cases |
Revision 042df5f by Stefan Werner May 3, 2021, 20:07 (GMT) |
Cycles standalone: Fixed macOS dependencies. Added IOKit and Accerelate as linked frameworks where necessary. |
Revision 8216b75 by Hans Goudey May 3, 2021, 17:29 (GMT) |
Geometry Nodes: Initial basic curve data support This patch adds initial curve support to geometry nodes. Currently there is only one node available, the "Curve to Mesh" node, T87428. However, the aim of the changes here is larger than just supporting curve data in nodes-- it also uses the opportunity to add better spline data structures, intended to replace the existing curve evaluation code. The curve code in Blender is quite old, and it's generally regarded as some of the messiest, hardest-to-understand code as well. The classes in `BKE_spline.hh` aim to be faster, more extensible, and much more easily understandable. Further explanation can be found in comments in that file. Initial builtin spline attributes are supported-- reading and writing from the `cyclic` and `resolution` attributes works with any of the attribute nodes. Also, only Z-up normal calculation is implemented at the moment, and tilts do not apply yet. **Limitations** - For now, you must bring curves into the node tree with an "Object Info" node. Changes to the curve modifier stack will come later. - Converting to a mesh is necessary to visualize the curve data. Further progress can be tracked in: T87245 Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes Differential Revision: https://developer.blender.org/D11091 |
Revision c9d8167 by Antonio Vazquez May 3, 2021, 15:10 (GMT) |
Merge branch 'blender-v2.93-release' |
Revision 55bf704 by Antonio Vazquez May 3, 2021, 15:10 (GMT) |
Fix T88005: GPencil inverse fill leaves unwanted line at viewport edge. There was a function to set 2 pixels wide for inverse filling, but this must not be done in the borders of the image. Now, the borders are checked before set 2 pixels. |
Revision 73a7660 by Philipp Oeser May 3, 2021, 14:57 (GMT) |
Merge branch 'blender-v2.93-release' |
Revision 29e5504 by Philipp Oeser May 3, 2021, 14:49 (GMT) |
Fix T87926: Transform menu has operators guaranteed to not pass poll in certain modes Reported for ops.transform.vertex_warp and ops.transform.vertex_random. Polling will check with ED_transverts_check_obedit, if we know it will fail e.g. for pose mode, we can do the same check in the UI already. Maniphest Tasks: T87926 Differential Revision: https://developer.blender.org/D11128 |
Revision 888a697 by Campbell Barton May 3, 2021, 14:44 (GMT) |
Cleanup: spelling |
Revision 12d8720 by Campbell Barton May 3, 2021, 14:39 (GMT) |
WM: disable idle event handling timer when simulating events |
Revision 2f615ad by Sergey Sharybin May 3, 2021, 14:30 (GMT) |
Fix wrong tracking curves after changing clip offset The issue was caused by frame start/offset change triggering clip reload, which was happening with a hardcoded scene frame index of 1, which could be outside of the actual clip frames. Solved by removing source change tag from the frame start/offset update. The source doesn't really change: the resolution will stay the same, as well as media type, its duration. So the tag was not needed. |
Revision 0ac6852 by Sergey Sharybin May 3, 2021, 14:30 (GMT) |
Movieclip: Use first clip frame for size detection Using scene frame 1 is not reliable in cases when there is a frame offset is involved. Using frame 1 seems more reliable, although might still fail under certain circumstances. More reliable fix would require a deeper change in the data structure and the logic about frame loading and size detection. |
Revision 9f1e20e by Kévin Dietrich May 3, 2021, 14:20 (GMT) |
Alembic Procedural: precompute vertex normals This precomputes vertex normals in the procedural and caches them in case none are found in the archive. This only applies to polygon meshes, as subdivision meshes are yet to be subdivided, so it is useless to do this computation. The goal here is to speed up data updates between frames, as computing normals shows up in profiles even for large objects. This saves around 16% of update time for a production file. |
Revision e2c671e by Kévin Dietrich May 3, 2021, 14:19 (GMT) |
Alembic Procedural: refactor data reading This splits the data reading logic from the AlembicObject class and moves it to separate files to better enforce a separation of concern. The goal was to simplify and improve the logic to read data from an Alembic archive. Since the procedural loads data for the entire animation, this requires looping over the frame range and looking up data for each frame. Previously those loops would be duplicated over the entire code causing divergences in how we might skip or deduplicate data across frames (if only some data change over time and not other on the same object, e.g. vertices and triangles might not have the same animation times), and therefore, bugs. Now, we only use a single function with callback to loop over the geometry data for each requested frame, and another one to loop over attributes. Given how attributes are accessed it is a bit tricky to simplify further and only use a ingle function, however, this is left as a further improvement as it is not impossible. To read the data, we now use a set of structures to hold which data to read. Those structures might seem redundant with the Alembic schemas as they are somewhat a copy of the schemas' structures, however they will allow us in the long run to treat the data of one object type as the data of another object type (e.g. to ignore subdivision, or only loading the vertices as point clouds). For attributes, this new system allows us to read arbitrary attributes, although with some limitations still: * only subdivision and polygon meshes are supported due to lack of examples for curve data; * some data types might be missing: we support float, float2, float3, booleans, normals, uvs, rgb, and rbga at the moment, other types can be trivially added * some attribute scopes (or domains) are not handled, again, due to lack of example files * color types are always interpreted as vertex colors |
Revision 3e48633 by Campbell Barton May 3, 2021, 14:17 (GMT) |
Cleanup: use boolean for has_event variable & return value |
Revision efe9928 by Philipp Oeser May 3, 2021, 13:56 (GMT) |
Merge branch 'blender-v2.93-release' |
Revision 04905c5 by Philipp Oeser May 3, 2021, 13:50 (GMT) |
Fix T87969: crash accesing FaceMaps / PaintMask data in editmode Workaround for crash when accessing FaceMaps / PaintMask data in editmode, just disallow access in editmode as is done with UVs. Same fix as in {rB3e2619b3e72a}. Maniphest Tasks: T87969 Differential Revision: https://developer.blender.org/D11146 |
Revision 2e9dc2b by Sergey Sharybin May 3, 2021, 13:40 (GMT) |
Merge branch 'blender-v2.93-release' |
Revision 04b90ee by Sergey Sharybin May 3, 2021, 13:37 (GMT) |
Fix compilation error after recent compositor fix Apparently, there is no emplace semantic available in the Vector in the stable branch. |
Revision 2b78d3d by Sergey Sharybin May 3, 2021, 13:11 (GMT) |
Merge branch 'blender-v2.93-release' |
Revision 1b4f0bf by Sergey Sharybin May 3, 2021, 13:07 (GMT) |
Fix T87989: Crash using OpenCL in compositor Initial report was mentioning the Classroom demo scene, but this is probably because the scene was pre-configured to be used with OpenCL. Would expect any OpenCL compositing to be failing prior to this fix. The reason why crash was happening is due to OpenCL queue being released from OpenCLDevice destructor. Is not that obvious, but when Vector (including std::vector) is holding elements by value a destructor will be called on "old" memory when vector capacitance changes. Solved by making forbidding copy semantic for compositor devices and forcing move semantic to be used. Also use emplace semantic in the devices vector initialization. |
|
|
|


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