The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
This gives better asserts in debug builds through use of Span, more
safety when name convention attributes happen to have different types
or domains, and simpler code in some cases. But the main reasoning is to
avoid relying on the specifics of CustomData more to allow us to replace
it in the future.
This adds a new "Active Camera" input geometry node, per #105761.
The node outputs the the scene's current active camera. It is available
from Input > Scene > Active Camera in the geometry nodes Add menu.
Typical usage would be to connect this node to an Object Info node to
obtain its transform. This works as expected when the camera's
transform is animated, and also when there are markers on the timeline
that change the active camera.
In order to support the aforementioned changes in the active camera,
this implementation adds depsgraph relations for all cameras referenced
by timeline markers. This eliminates the complexity of updating the
depsgraph whenever the scene switches to a different active camera,
but of course it comes at the cost of including more objects than
strictly necessary in the depsgraph for scenes that switch cameras.
Dynamically updating the depsgraph upon camera changes could be a
future improvement if there proves to be sufficient need for it.
Pull Request: https://projects.blender.org/blender/blender/pulls/113431
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
For context, see 6d09fa3577. Overall, these values were still
written in some cases, but never used. Nowadays the viewer node and
attribute overlays give even better answers to these needs.
Automatic memory management and clearer ownership! Requires
removing `MEM_CXX_CLASS_ALLOC_FUNCS` from `MeshRuntime`,
but that's used very inconsistently anyway, and `MeshRuntime` isn't
that large.
Exposed by 383a145a19.
Think the issue actually started in cfa53e0fbe, since then the new
destination normals were only filled from the first array copy onwards
(probably hidden by some recalculation of normals somewhere?).
In any case, starting the destination normals array with what we have
from the input mesh normals and then resizing the array (instead of
reinitializing it from scratch) fixes this.
Pull Request: https://projects.blender.org/blender/blender/pulls/115612
This avoids some duplication between the modifier and operator evaluation
contexts and also makes it easier to make independent from a specific
evaluation context (so e.g. the simulation nodes code shouldn't care whether
it's used from a modifier or operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/115512
Inlining the functions is simpler nowadays, since there are utility
functions to copy spans and tag the mesh caches dirty. Also use an
array instead of a raw pointer for multires.
Resolves#103789
In Simple Solidify's mode edge weights created by "Bevel Convex"
disappear, if edge weight is added to original mesh. From technical
side problem is identical to the one in #114860.
If original mesh doesn't have layer "bevel_weight_edge" option "Bevel
Convex" works fine. All bevels disappear after one edge gets bevel
weight. Except ones corresponding newly added weight. In patched
version weights created by "Convex Bevel" stay. Also manually added
weight can be observed on the edge of inner cube.
Second problem is when am original plane has one vertex with bevel
weight 1.0, but no bevel in result. If to change Solidify's mode from
"Simple" to "Complex" bevel appears. Patch adds this behavior to the
"Simple" mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/115258
`GroupNodeComputeContext` is the more correct name because it's
specifically about a group node that invokes another node tree.
The old name makes it sound like it should be used because a node group
is invoked but does not tell anything about what invoked it.
For example, the current context in a node group can also be a
`ModifierComputeContext` if that's what invoked it.
"Solidify" modifier in "Complex" mode was creating redundant layer
"bevel_weight_edge.001", if mesh has bevel weights for vertex set.
All modifier's custom edge bevel weight calculations went there and got lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/115178
This struct is currently defined in the `functions` module but not actually used there. It's only used by the geometry nodes module, with an indirect dependency from blenkernel via simulation zone baking. This scope is problematic when adding grids as socket data, which should not be part of the functions module.
The `ValueOrField` struct is now moved to blenkernel, so it can be more easily extended to other kinds of data that might be passed around by geometry nodes sockets in future. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/115087
Use float3, float3x3, and Array for data used for mesh crazyspace
calculation. Propagate the change wherever necessary to not add
more casting to the old C types.
Because `ObjectRuntime` (and therefore `DEGObjectIterData`) became
non-trivial structs, the code that swaps iterators for RNA depsgraph
object iteration had to be changed a bit to be more friendly to C++
memory semantics.
Pull Request: https://projects.blender.org/blender/blender/pulls/114998
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
Cleanup talked about in the previous semi-related PR, #114501
- saacos, saasin, sasqrt have been 100% identical to saacosf,
saasinf, sasqrtf since 2012.
- For all the above, there exist more intuitively named safe_acosf,
safe_asinf, safe_sqrtf that do the same thing, so switch all code to those.
Pull Request: https://projects.blender.org/blender/blender/pulls/114593
Function Module Inclusive Time Exclusive Time
--------------------------------------------------------------------------
mesh_render_data_update_normals blender 297.51 0.00
315 -> 297
acos() usage in all places related to normal calculations shows up in the
profiler. Given that "angle between faces" is only additional heuristic
weight in there (the effect of it at all is very subtle), approximate but
faster version of acos() might be just fine. Especially since some other
parts of Blender (e.g. mikktspace) use approximate acos in a conceptually
the same part.
- Adds safe_acos_approx() to BLI_math_base.hh. Implementation the same
as already exists in Cycles; max error 0.00258 degrees. Between 2x and 4x
faster in my tests.
- Changes all normals related calculations to use the function above instead
of saacos.
Computing normals on a Stanford Lucy (14m verts) mesh:
- Mac (arm64, M1 Max): 247ms -> 229ms
- Win (x64, Ryzen 5950X): 276ms -> 250ms
All places that are about "normal calculation" were changed, including e.g.
Corrective Smooth modifier. Applying that one to the same 14m vertices mesh,
Mac M1 Max: 9.96s -> 9.76s
Tiny changes in several test output expectations w.r.t. normals are
observed, these were reviewed and updated expectations checked in svn.
Pull Request: https://projects.blender.org/blender/blender/pulls/114501
Each node group asset exposes various properties through sockets.
Although they can generally be considered user-created data, for
built-in assets they are also part of the UI and should be
translated--especially since more modifiers should be migrated to
Geometry Nodes in the future.
This commit enables the translation of those properties in the
Modifier Properties editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/114256
The issue crash was caused by non-safe cast from a bare C array
float[4][4] to float4x4*. Such cast is not safe because it might
break alignment.
Modified the code so that the transform matrices are passed by
value.
Technically it could mean higher memory usage, but odds that the
actual geometry which is a part of boolean operation consumes much
more memory. Additionally, avoiding indirection could potentially
lead to better performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/114421
Currently the node tool node group and data-blocks referenced by it
may not be part of the active dependency graph. This means we
cannot retrieve their evaluated geometry when executing the operator.
Since operators almost always use the evaluated geometry of other
objects, and since geometry nodes is mostly set up to deal with
evaluated data-blocks currently, this must be fixed.
Instead, set up a temporary dependency graph and add the selected
objects and the data-blocks used by the node group. That graph is
evaluated to give simple access to evaluated data-blocks.
Unfortunately this will cause more work than necessary in a few ways:
1. Selected objects are reevaluated an extra time before execution.
2. All data-blocks referenced by the group are completely evaluated again.
3. The node group itself is reevaluated, which recreates the function graph.
These may or may not become bottlenecks in the future, but it's best to
keep it simple late in the release process. And between a completely
broken feature and a potentially slow feature, the choice is clear!
Pull Request: https://projects.blender.org/blender/blender/pulls/114293
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
`EdgeHash` was replaced by `VectorSet`, but the changes in the data
structure hid some other changes, causing incorrect indices to be used.
Instead use `Map` and explicitly build the indices similar to how they
were counted in a separate loop before.
Caused by: 425b871607
Known limitations to be addressed separately:
* We are not warning/keeping track of the named layers.
* There is no lookup for layers (groups) yet.
Ref !113908.
