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 MVert;
|
|
|
|
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.
|
|
|
|
*/
|
2012-05-12 20:39:39 +00:00
|
|
|
struct MVert *(*getVertArray)(DerivedMesh *dm);
|
|
|
|
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)
|
|
|
|
*/
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*copyVertArray)(DerivedMesh *dm, struct MVert *r_vert);
|
|
|
|
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
|