Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-07-26Cleanup: missed comment in D12029Charlie Jolly
No functional change.
2021-07-26Geometry Nodes: Fix vector math project bugCharlie Jolly
Implementation is incorrect compared to Cycles/Eevee. Reported by @DrDubosc in comments of T88922. Differential Revision: https://developer.blender.org/D12029
2021-06-04Nodes: Add Multiply Add to Vector Math nodesCharlie Jolly
Cycles, Eevee, OSL, Geo, Attribute This operator provides consistency with the standard math node. Allows users to use a single node instead of two nodes for this common operation. Reviewed By: HooglyBoogly, brecht Differential Revision: https://developer.blender.org/D10808
2021-03-26Cleanup: clang-formatCampbell Barton
2021-03-23Nodes: Add Refract and Faceforward functions to Vector Maths nodesCharlie Jolly
Cycles, Eevee, OSL, Geo, Attribute Based on outdated refract patch D6619 by @cubic_sloth `refract` and `faceforward` are standard functions in GLSL, OSL and Godot shader languages. Adding these functions provides Blender shader artists access to these standard functions. Reviewed By: brecht Differential Revision: https://developer.blender.org/D10622
2021-01-11Geometry Nodes: Attribute Vector Math NodeHans Goudey
This patch implements the same operations and interface as the regular vector math node, but it runs for every element of the attribute. This should expand what's possible with geometry nodes quite a bit. Differential Revision: https://developer.blender.org/D9914
2020-12-17Geometry Nodes: Point separate and attribute compare nodesHans Goudey
This patch adds two related nodes, a node for separating points and mesh vertices based on a boolean attribute input, and a node for creating boolean attributes with comparisons. See the differential for an example file and video. Point Separate (T83059) The output in both geometries is just point data, contained in the mesh and point cloud components, depending which components had data in the input geometry. Any points with the mask attribute set to true will be moved from the first geometry output to the second. This means that for meshes, all edge and face data will be removed. Any point domain attributes are moved to the correct output geometry as well. Attribute Compare (T83057) The attribute compare does the "Equal" and "Not Equal" operations by comparing vectors and colors based on their distance from each other. For other operations, the comparison is between the lengths of the vector inputs. In general, the highest complexity data type is used for the operation, and a new function to determine that is added. Differential Revision: https://developer.blender.org/D9876
2020-12-02Geometry Nodes: initial scattering and geometry nodesJacques Lucke
This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix