2022-02-11 09:07:11 +11:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
* Copyright 2001-2002 NaN Holding BV. All rights reserved. */
|
2005-03-27 20:34:18 +00:00
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#pragma once
|
2005-03-27 20:34:18 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
2013-09-12 03:02:50 +00:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* Basic design of the DerivedMesh system:
|
|
|
|
*
|
|
|
|
* DerivedMesh is a common set of interfaces for mesh systems.
|
|
|
|
*
|
2012-06-27 17:48:39 +00:00
|
|
|
* There are three main mesh data structures in Blender:
|
|
|
|
* #Mesh, #CDDerivedMesh and #BMesh.
|
|
|
|
*
|
2018-06-01 18:19:39 +02:00
|
|
|
* These, and a few others, all implement DerivedMesh interfaces,
|
|
|
|
* which contains unified drawing interfaces, a few utility interfaces,
|
|
|
|
* and a bunch of read-only interfaces intended mostly for conversion from
|
2012-03-03 20:19:11 +00:00
|
|
|
* one format to another.
|
|
|
|
*
|
|
|
|
* All Mesh structures in blender make use of CustomData, which is used to store
|
|
|
|
* per-element attributes and interpolate them (e.g. uvs, vcols, vgroups, etc).
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* Mesh is the "serialized" structure, used for storing object-mode mesh data
|
|
|
|
* and also for saving stuff to disk. Its interfaces are also what DerivedMesh
|
|
|
|
* uses to communicate with.
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* CDDM is a little mesh library, that uses Mesh data structures in the backend.
|
|
|
|
* It's mostly used for modifiers, and has the advantages of not taking much
|
|
|
|
* resources.
|
|
|
|
*
|
|
|
|
* BMesh is a full-on brep, used for editmode, some modifiers, etc. It's much
|
|
|
|
* more capable (if memory-intensive) then CDDM.
|
|
|
|
*
|
|
|
|
* DerivedMesh is somewhat hackish. Many places assumes that a DerivedMesh is
|
|
|
|
* a CDDM (most of the time by simply copying it and converting it to one).
|
|
|
|
* CDDM is the original structure for modifiers, but has since been superseded
|
|
|
|
* by BMesh, at least for the foreseeable future.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2021-07-03 23:08:40 +10:00
|
|
|
* NOTE: This structure is read-only, for all practical purposes.
|
2009-07-17 01:57:12 +00:00
|
|
|
* At some point in the future, we may want to consider
|
|
|
|
* creating a replacement structure that implements a proper
|
|
|
|
* abstract mesh kernel interface. Or, we can leave this
|
|
|
|
* as it is and stick with using BMesh and CDDM.
|
|
|
|
*/
|
|
|
|
|
2013-09-01 15:01:15 +00:00
|
|
|
#include "BLI_compiler_attrs.h"
|
|
|
|
|
2022-05-15 20:27:28 +02:00
|
|
|
#include "DNA_customdata_types.h"
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2020-03-02 15:07:49 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2019-01-28 21:08:24 +11:00
|
|
|
struct BMEditMesh;
|
2012-05-10 20:33:09 +00:00
|
|
|
struct CCGElem;
|
|
|
|
struct CCGKey;
|
Refactor CDData masks, to have one mask per mesh elem type.
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
2019-03-07 11:13:40 +01:00
|
|
|
struct CustomData_MeshMasks;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Depsgraph;
|
2006-08-28 01:12:36 +00:00
|
|
|
struct MEdge;
|
|
|
|
struct MFace;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Mesh;
|
2005-07-26 00:45:19 +00:00
|
|
|
struct ModifierData;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Object;
|
|
|
|
struct Scene;
|
2005-03-27 20:34:18 +00:00
|
|
|
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
/*
|
2022-06-01 15:11:56 +10:00
|
|
|
* NOTE: all #MFace interfaces now officially operate on tessellated data.
|
|
|
|
* Also, the #MFace orig-index layer indexes #MPoly, not #MFace.
|
2012-03-03 20:19:11 +00:00
|
|
|
*/
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
|
2012-03-06 02:40:08 +00:00
|
|
|
/* keep in sync with MFace/MPoly types */
|
|
|
|
typedef struct DMFlagMat {
|
|
|
|
short mat_nr;
|
|
|
|
char flag;
|
|
|
|
} DMFlagMat;
|
|
|
|
|
2010-01-06 12:05:46 +00:00
|
|
|
typedef enum DerivedMeshType {
|
|
|
|
DM_TYPE_CDDM,
|
2019-04-16 16:40:47 +02:00
|
|
|
DM_TYPE_CCGDM,
|
2010-01-06 12:05:46 +00:00
|
|
|
} DerivedMeshType;
|
|
|
|
|
2005-03-27 20:34:18 +00:00
|
|
|
typedef struct DerivedMesh DerivedMesh;
|
|
|
|
struct DerivedMesh {
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Private DerivedMesh data, only for internal DerivedMesh use */
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
CustomData vertData, edgeData, faceData, loopData, polyData;
|
2011-11-30 18:03:56 +00:00
|
|
|
int numVertData, numEdgeData, numTessFaceData, numLoopData, numPolyData;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
int needsFree; /* checked on ->release, is set to 0 for cached results */
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
int deformedOnly; /* set by modifier stack if only deformed from original */
|
2010-01-06 12:05:46 +00:00
|
|
|
DerivedMeshType type;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
/**
|
|
|
|
* \warning Typical access is done via #getLoopTriArray, #getNumLoopTri.
|
|
|
|
*/
|
|
|
|
struct {
|
2019-04-27 12:07:07 +10:00
|
|
|
/* WARNING! swapping between array (ready-to-be-used data) and array_wip
|
|
|
|
* (where data is actually computed) shall always be protected by same
|
|
|
|
* lock as one used for looptris computing. */
|
2017-09-19 13:57:46 +02:00
|
|
|
struct MLoopTri *array, *array_wip;
|
2015-07-17 03:36:03 +10:00
|
|
|
int num;
|
|
|
|
int num_alloc;
|
|
|
|
} looptris;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-07-02 20:21:19 +02:00
|
|
|
short tangent_mask; /* which tangent layers are calculated */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-08-11 16:51:19 +02:00
|
|
|
/** Loop tessellation cache (WARNING! Only call inside threading-protected code!) */
|
2015-07-17 03:36:03 +10:00
|
|
|
void (*recalcLoopTri)(DerivedMesh *dm);
|
|
|
|
/** accessor functions */
|
|
|
|
const struct MLoopTri *(*getLoopTriArray)(DerivedMesh *dm);
|
|
|
|
int (*getNumLoopTri)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-13 15:13:59 +00:00
|
|
|
/* Misc. Queries */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
/* Also called in Editmode */
|
2005-03-27 21:27:12 +00:00
|
|
|
int (*getNumVerts)(DerivedMesh *dm);
|
2006-08-28 01:12:36 +00:00
|
|
|
int (*getNumEdges)(DerivedMesh *dm);
|
2011-11-30 18:03:56 +00:00
|
|
|
int (*getNumLoops)(DerivedMesh *dm);
|
2011-11-29 13:01:51 +00:00
|
|
|
int (*getNumPolys)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Return a pointer to the entire array of verts/edges/face from the
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
* derived mesh. if such an array does not exist yet, it will be created,
|
|
|
|
* and freed on the next ->release(). consider using getVert/Edge/Face if
|
|
|
|
* you are only interested in a few verts/edges/faces.
|
|
|
|
*/
|
Mesh: Move positions to a generic attribute
**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
2023-01-10 00:10:43 -05:00
|
|
|
/**
|
|
|
|
* \warning The real return type is `float(*)[3]`.
|
|
|
|
*/
|
|
|
|
float *(*getVertArray)(DerivedMesh *dm);
|
2012-05-12 20:39:39 +00:00
|
|
|
struct MEdge *(*getEdgeArray)(DerivedMesh *dm);
|
|
|
|
struct MLoop *(*getLoopArray)(DerivedMesh *dm);
|
|
|
|
struct MPoly *(*getPolyArray)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Copy all verts/edges/faces from the derived mesh into
|
2006-08-28 01:12:36 +00:00
|
|
|
* *{vert/edge/face}_r (must point to a buffer large enough)
|
|
|
|
*/
|
Mesh: Move positions to a generic attribute
**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
2023-01-10 00:10:43 -05:00
|
|
|
void (*copyVertArray)(DerivedMesh *dm, float (*r_positions)[3]);
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*copyEdgeArray)(DerivedMesh *dm, struct MEdge *r_edge);
|
|
|
|
void (*copyLoopArray)(DerivedMesh *dm, struct MLoop *r_loop);
|
|
|
|
void (*copyPolyArray)(DerivedMesh *dm, struct MPoly *r_poly);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Return a pointer to the entire array of vert/edge/face custom data
|
2006-08-28 01:12:36 +00:00
|
|
|
* from the derived mesh (this gives a pointer to the actual data, not
|
|
|
|
* a copy)
|
|
|
|
*/
|
2013-03-29 06:25:22 +00:00
|
|
|
void *(*getVertDataArray)(DerivedMesh *dm, int type);
|
|
|
|
void *(*getEdgeDataArray)(DerivedMesh *dm, int type);
|
2013-04-03 20:10:08 +00:00
|
|
|
void *(*getLoopDataArray)(DerivedMesh *dm, int type);
|
2013-03-29 06:25:22 +00:00
|
|
|
void *(*getPolyDataArray)(DerivedMesh *dm, int type);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Optional grid access for subsurf */
|
2009-11-25 13:11:44 +00:00
|
|
|
int (*getNumGrids)(DerivedMesh *dm);
|
|
|
|
int (*getGridSize)(DerivedMesh *dm);
|
2012-05-12 20:39:39 +00:00
|
|
|
struct CCGElem **(*getGridData)(DerivedMesh *dm);
|
|
|
|
int *(*getGridOffset)(DerivedMesh *dm);
|
2012-05-10 20:33:09 +00:00
|
|
|
void (*getGridKey)(DerivedMesh *dm, struct CCGKey *key);
|
2012-05-12 20:39:39 +00:00
|
|
|
DMFlagMat *(*getGridFlagMats)(DerivedMesh *dm);
|
|
|
|
unsigned int **(*getGridHidden)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Direct Access Operations
|
|
|
|
* - Can be undefined
|
|
|
|
* - Must be defined for modifiers that only deform however */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Get vertex location, undefined if index is not valid */
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*getVertCo)(DerivedMesh *dm, int index, float r_co[3]);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Get smooth vertex normal, undefined if index is not valid */
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*getVertNo)(DerivedMesh *dm, int index, float r_no[3]);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Release reference to the DerivedMesh. This function decides internally
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
* if the DerivedMesh will be freed, or cached for later use. */
|
2005-03-27 20:34:18 +00:00
|
|
|
void (*release)(DerivedMesh *dm);
|
|
|
|
};
|
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* Utility function to initialize a #DerivedMesh's function pointers to
|
|
|
|
* the default implementation (for those functions which have a default).
|
|
|
|
*/
|
2006-08-28 01:12:36 +00:00
|
|
|
void DM_init_funcs(DerivedMesh *dm);
|
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* Utility function to initialize a #DerivedMesh for the desired number
|
|
|
|
* of vertices, edges and faces (doesn't allocate memory for them, just
|
|
|
|
* sets up the custom data layers)>
|
|
|
|
*/
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_init(DerivedMesh *dm,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
2020-09-04 20:59:13 +02:00
|
|
|
int numTessFaces,
|
2015-07-02 16:20:22 +10:00
|
|
|
int numLoops,
|
|
|
|
int numPolys);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* Utility function to initialize a DerivedMesh for the desired number
|
|
|
|
* of vertices, edges and faces, with a layer setup copied from source
|
|
|
|
*/
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_from_template(DerivedMesh *dm,
|
|
|
|
DerivedMesh *source,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
2020-09-04 20:59:13 +02:00
|
|
|
int numTessFaces,
|
2015-07-02 16:20:22 +10:00
|
|
|
int numLoops,
|
|
|
|
int numPolys);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-11-25 01:14:39 +11:00
|
|
|
/**
|
|
|
|
* Utility function to release a DerivedMesh's layers
|
2020-09-02 19:10:18 +02:00
|
|
|
* returns true if DerivedMesh has to be released by the backend, false otherwise.
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2020-09-02 19:10:18 +02:00
|
|
|
bool DM_release(DerivedMesh *dm);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* set the #CD_FLAG_NOCOPY flag in custom data layers where the mask is
|
|
|
|
* zero for the layer type, so only layer types specified by the mask
|
|
|
|
* will be copied
|
|
|
|
*/
|
Refactor CDData masks, to have one mask per mesh elem type.
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
2019-03-07 11:13:40 +01:00
|
|
|
void DM_set_only_copy(DerivedMesh *dm, const struct CustomData_MeshMasks *mask);
|
2006-12-05 17:42:03 +00:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/* -------------------------------------------------------------------- */
|
|
|
|
/** \name Custom Data Layer Access Functions
|
|
|
|
*
|
|
|
|
* \return pointer to first data layer which matches type (a flat array)
|
|
|
|
* if they return NULL, data doesn't exist.
|
|
|
|
* \note these return pointers - any change modifies the internals of the mesh.
|
|
|
|
* \{ */
|
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
void *DM_get_vert_data_layer(struct DerivedMesh *dm, int type);
|
|
|
|
void *DM_get_edge_data_layer(struct DerivedMesh *dm, int type);
|
2011-11-29 05:09:54 +00:00
|
|
|
void *DM_get_poly_data_layer(struct DerivedMesh *dm, int type);
|
2012-02-05 11:30:26 +00:00
|
|
|
void *DM_get_loop_data_layer(struct DerivedMesh *dm, int type);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/** \} */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Custom data copy functions
|
2006-08-28 01:12:36 +00:00
|
|
|
* copy count elements from source_index in source to dest_index in dest
|
2021-12-07 17:19:15 +11:00
|
|
|
* these copy all layers for which the CD_FLAG_NOCOPY flag is not set.
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_copy_vert_data(struct DerivedMesh *source,
|
|
|
|
struct DerivedMesh *dest,
|
|
|
|
int source_index,
|
|
|
|
int dest_index,
|
|
|
|
int count);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* Ensure the array is large enough.
|
|
|
|
*
|
|
|
|
* \note This function must always be thread-protected by caller.
|
|
|
|
* It should only be used by internal code.
|
|
|
|
*/
|
2015-07-17 03:36:03 +10:00
|
|
|
void DM_ensure_looptri_data(DerivedMesh *dm);
|
2014-07-21 12:02:05 +02:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* Interpolates vertex data from the vertices indexed by `src_indices` in the
|
|
|
|
* source mesh using the given weights and stores the result in the vertex
|
|
|
|
* indexed by `dest_index` in the `dest` mesh.
|
|
|
|
*/
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_interp_vert_data(struct DerivedMesh *source,
|
|
|
|
struct DerivedMesh *dest,
|
|
|
|
int *src_indices,
|
|
|
|
float *weights,
|
|
|
|
int count,
|
|
|
|
int dest_index);
|
|
|
|
|
2022-01-07 11:38:08 +11:00
|
|
|
void mesh_get_mapped_verts_coords(struct Mesh *me_eval, float (*r_cos)[3], int totcos);
|
2005-03-29 16:43:39 +00:00
|
|
|
|
2021-12-07 17:19:15 +11:00
|
|
|
/**
|
|
|
|
* Same as above but won't use render settings.
|
|
|
|
*/
|
2018-10-09 16:52:46 +11:00
|
|
|
struct Mesh *editbmesh_get_eval_cage(struct Depsgraph *depsgraph,
|
2022-02-14 12:05:54 -06:00
|
|
|
const struct Scene *scene,
|
|
|
|
struct Object *obedit,
|
Refactor CDData masks, to have one mask per mesh elem type.
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
2019-03-07 11:13:40 +01:00
|
|
|
struct BMEditMesh *em,
|
|
|
|
const struct CustomData_MeshMasks *dataMask);
|
2018-12-06 09:38:08 +11:00
|
|
|
struct Mesh *editbmesh_get_eval_cage_from_orig(struct Depsgraph *depsgraph,
|
2022-02-14 12:05:54 -06:00
|
|
|
const struct Scene *scene,
|
2020-09-04 20:59:13 +02:00
|
|
|
struct Object *obedit,
|
Refactor CDData masks, to have one mask per mesh elem type.
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
2019-03-07 11:13:40 +01:00
|
|
|
const struct CustomData_MeshMasks *dataMask);
|
2014-08-01 15:42:17 +02:00
|
|
|
|
2019-08-22 06:28:35 +10:00
|
|
|
float (*editbmesh_vert_coords_alloc(struct BMEditMesh *em, int *r_vert_len))[3];
|
2022-02-14 12:05:54 -06:00
|
|
|
bool editbmesh_modifier_is_enabled(const struct Scene *scene,
|
2020-10-26 17:07:58 +11:00
|
|
|
const struct Object *ob,
|
2018-10-09 15:04:51 +11:00
|
|
|
struct ModifierData *md,
|
|
|
|
bool has_prev_mesh);
|
2018-04-06 12:07:27 +02:00
|
|
|
void makeDerivedMesh(struct Depsgraph *depsgraph,
|
2022-02-14 12:05:54 -06:00
|
|
|
const struct Scene *scene,
|
2018-04-06 12:07:27 +02:00
|
|
|
struct Object *ob,
|
2019-03-27 19:07:16 +01:00
|
|
|
const struct CustomData_MeshMasks *dataMask);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2020-03-02 15:07:49 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|