**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
Missed these changes in [0].
Also replace designated initializers in some C code, as it's not used
often and would need to be removed when converting to C++.
[0] e555ede626
Use struct identifiers in comments before the value.
This has some advantages:
- The struct identifiers didn't mix well with other code-comments,
where other comments were wrapped onto the next line.
- Minor changes could re-align all other comments in the struct.
- PyVarObject_HEAD_INIT & tp_name are no longer placed on the same line.
Remove overly verbose comments copied from PyTypeObject (Python v2.x),
these aren't especially helpful and get outdated.
Also corrected some outdated names:
- PyTypeObject.tp_print -> tp_vectorcall_offset
- PyTypeObject.tp_reserved -> tp_as_async
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d. This aligns better with
existing naming where the shorter names are much more common.
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7, 410a6efb74). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
Instead of accessing the `CD_NORMAL` layer directly,
use the proper API for accessing mesh normals. Even if the
layer exists, the values might be incorrect due to a deformation.
Related to ef0e21f0ae, 969c4a45ce, and T95839.
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
2 sided faces aren't supported and will cause problems in many areas
of Blender's code.
Removing (implied) support for faces with fewer than 3 sides
means the total number of triangles is known ahead of time.
This simplifies adding support for multi-threading and partial updates
to an existing tessellation - as the face and loop indices can be used
to access the range of triangles associated with a face.
Also correct outdated comments.
Functions `mesh_create_eval_final_view()` and
`mesh_create_eval_final_render()` were doing the exact same thing,
except for a hack introduced in d3eb9dddd6 (2012-10-08, Better fix for
T32846: dupligroup messes up particle instancing on rendering) that
appears to be no longer necessary. Besides that, these functions had
confusing names. Their functionality changed over time, and whether to
do for-render or for-viewport evaluation is now actually determined by
the depsgraph evaluation mode. This means that the `..._render` function
could evaluate a mesh with viewport settings, and vice versa.
The functions are now merged into `mesh_create_eval_final()`, and the
hack has been removed. The `OB_NO_PSYS_UPDATE` flag has been removed
entirely (instead of keeping it around as deprecated flag), because it
was always only temporarily set on objects during mesh evaluation and
thus not saved to the blend file.
No expected functional changes as far as users are concerned.
The problem is caused by a lack of prediction in the `isect_line_segment_tri_v3`
that incorrectly confirms some intersections of coplanar segments to the triangle.
The solution is to use another algorithm to detect intersections.
This also resulted in a slight improvement in the performance:
- 1min 17sec to 1min 6sec in my test file
Differential Revision: https://developer.blender.org/D8500
While it might be handy to have type-less functionality which is
similar to how C++ math is implemented it can not be easily achieved
with just preprocessor in a way which does not have side-effects on
wrong usage.
There macros where often used on a non-trivial expression, and there
was at least one usage where it was causing an actual side effect/bug
on Windows (see change around square_f(sh[index++]) in studiolight.c).
For such cases it is handy to have a function which is guaranteed to
have zero side-effects. The motivation behind actually removing the
macros is that there is already a way to do similar calculation. Also,
not having such macros is a way to guarantee that its usage is not
changed in a way which have side-effects and that it's not used as an
inspiration for cases where it should not be used.
Differential Revision: https://developer.blender.org/D7051
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Would free evaluated mesh even when it was the one cached in runtime
data by depsgraph evaluation!
Also fixes the asserts about using non-eval object in some cases.
Passing depsgraph instead of scene, since a scene does not fully define the
state of object you want to use for the BVH.
Also, mesh_create_eval_final_view and mesh_create_eval_final_render are pretty
much the same, so mesh_create_eval_no_deform and
mesh_create_eval_no_deform_render are as well.
Issue reported on: T58734
Reviewers: sergey
https://developer.blender.org/D4032
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
