2006-08-28 01:12:36 +00:00
|
|
|
/*
|
2011-10-10 09:38:02 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2006 Blender Foundation.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*/
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup bke
|
|
|
|
|
* \section aboutcdderivedmesh CDDerivedMesh interface
|
2011-02-18 13:05:18 +00:00
|
|
|
* CDDerivedMesh (CD = Custom Data) is a DerivedMesh backend which stores
|
|
|
|
|
* mesh elements (vertices, edges and faces) as layers of custom element data.
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
|
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#ifndef __BKE_CDDERIVEDMESH_H__
|
|
|
|
|
#define __BKE_CDDERIVEDMESH_H__
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
#include "BKE_DerivedMesh.h"
|
2018-05-22 17:53:18 +02:00
|
|
|
#include "BKE_customdata.h"
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2009-05-18 08:46:04 +00:00
|
|
|
struct BMEditMesh;
|
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 DerivedMesh;
|
Add Custom Loop Normals.
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
|
|
|
struct MLoopNorSpaceArray;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Mesh;
|
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
|
|
|
struct Object;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
/* creates a new CDDerivedMesh */
|
2019-04-17 06:17:24 +02:00
|
|
|
struct DerivedMesh *CDDM_new(int numVerts, int numEdges, int numFaces, int numLoops, int numPolys);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
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
|
|
|
/* creates a CDDerivedMesh from the given Mesh, this will reference the
|
2012-03-03 20:19:11 +00:00
|
|
|
* original data in Mesh, but it is safe to apply vertex coordinates or
|
2012-03-09 00:41:09 +00:00
|
|
|
* calculate normals as those functions will automatically create new
|
2012-03-03 20:19:11 +00:00
|
|
|
* data to not overwrite the original */
|
2013-12-26 08:26:41 +11:00
|
|
|
struct DerivedMesh *CDDM_from_mesh(struct Mesh *mesh);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2018-04-25 15:38:26 +02:00
|
|
|
/* creates a CDDerivedMesh from the given Mesh with custom allocation type. */
|
2019-04-17 06:17:24 +02:00
|
|
|
struct DerivedMesh *CDDM_from_mesh_ex(struct Mesh *mesh,
|
|
|
|
|
eCDAllocType alloctype,
|
|
|
|
|
const struct CustomData_MeshMasks *mask);
|
2018-04-25 15:38:26 +02:00
|
|
|
|
2014-01-23 14:50:50 +01:00
|
|
|
struct DerivedMesh *CDDM_from_bmesh(struct BMesh *bm, const bool use_mdisps);
|
2012-10-24 07:24:11 +00:00
|
|
|
|
2009-05-18 08:46:04 +00:00
|
|
|
/* creates a CDDerivedMesh from the given BMEditMesh */
|
2019-04-17 06:17:24 +02:00
|
|
|
DerivedMesh *CDDM_from_editbmesh(struct BMEditMesh *em,
|
|
|
|
|
const bool use_mdisps,
|
|
|
|
|
const bool use_tessface);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2010-03-05 16:47:52 +00:00
|
|
|
/* creates a CDDerivedMesh from the given curve object */
|
|
|
|
|
struct DerivedMesh *CDDM_from_curve(struct Object *ob);
|
|
|
|
|
|
2010-03-08 13:49:13 +00:00
|
|
|
/* creates a CDDerivedMesh from the given curve object and specified dispbase */
|
|
|
|
|
/* useful for OrcoDM creation for curves with constructive modifiers */
|
2013-01-10 17:37:17 +00:00
|
|
|
DerivedMesh *CDDM_from_curve_displist(struct Object *ob, struct ListBase *dispbase);
|
2010-03-08 13:49:13 +00:00
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
/* Copies the given DerivedMesh with verts, faces & edges stored as
|
|
|
|
|
* custom element data.
|
|
|
|
|
*/
|
2012-01-29 21:59:47 +00:00
|
|
|
struct DerivedMesh *CDDM_copy(struct DerivedMesh *dm);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
/* creates a CDDerivedMesh with the same layer stack configuration as the
|
|
|
|
|
* given DerivedMesh and containing the requested numbers of elements.
|
2012-03-18 07:38:51 +00:00
|
|
|
* elements are initialized to all zeros
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
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 DerivedMesh *CDDM_from_template_ex(struct DerivedMesh *source,
|
2019-04-17 06:17:24 +02:00
|
|
|
int numVerts,
|
|
|
|
|
int numEdges,
|
|
|
|
|
int numFaces,
|
|
|
|
|
int numLoops,
|
|
|
|
|
int numPolys,
|
|
|
|
|
const struct CustomData_MeshMasks *mask);
|
|
|
|
|
struct DerivedMesh *CDDM_from_template(struct DerivedMesh *source,
|
|
|
|
|
int numVerts,
|
|
|
|
|
int numEdges,
|
|
|
|
|
int numFaces,
|
|
|
|
|
int numLoops,
|
|
|
|
|
int numPolys);
|
(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
|
|
|
|
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
|
|
|
/* applies vertex coordinates or normals to a CDDerivedMesh. if the MVert
|
|
|
|
|
* layer is a referenced layer, it will be duplicate to not overwrite the
|
|
|
|
|
* original
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
|
|
|
|
void CDDM_apply_vert_coords(struct DerivedMesh *cddm, float (*vertCoords)[3]);
|
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
|
|
|
void CDDM_apply_vert_normals(struct DerivedMesh *cddm, short (*vertNormals)[3]);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
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
|
|
|
/* recalculates vertex and face normals for a CDDerivedMesh
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2014-01-23 14:50:50 +01:00
|
|
|
void CDDM_calc_normals_mapping_ex(struct DerivedMesh *dm, const bool only_face_normals);
|
2012-01-06 00:12:24 +00:00
|
|
|
void CDDM_calc_normals_mapping(struct DerivedMesh *dm);
|
2012-01-06 00:45:07 +00:00
|
|
|
void CDDM_calc_normals(struct DerivedMesh *dm);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
void CDDM_calc_loop_normals(struct DerivedMesh *dm,
|
|
|
|
|
const bool use_split_normals,
|
|
|
|
|
const float split_angle);
|
|
|
|
|
void CDDM_calc_loop_normals_spacearr(struct DerivedMesh *dm,
|
|
|
|
|
const bool use_split_normals,
|
|
|
|
|
const float split_angle,
|
Add Custom Loop Normals.
This is the core code for it, tools (datatransfer and modifier) will come in next commits).
RNA api is already there, though.
See the code for details, but basically, we define, for each 'smooth fan'
(which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal),
a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store
custom normal as two angular factors inside that space. This allows to have custom normals
'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer.
Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals,
and be converted back into storage format at the end.
Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can
be rather heavy with high poly meshes.
Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
|
|
|
struct MLoopNorSpaceArray *r_lnors_spacearr);
|
2014-04-13 12:18:51 +02:00
|
|
|
|
2011-11-13 15:13:59 +00:00
|
|
|
/* reconstitute face triangulation */
|
2012-03-02 16:05:54 +00:00
|
|
|
void CDDM_recalc_tessellation(struct DerivedMesh *dm);
|
2014-01-23 14:50:50 +01:00
|
|
|
void CDDM_recalc_tessellation_ex(struct DerivedMesh *dm, const bool do_face_nor_cpy);
|
2011-02-27 06:19:40 +00:00
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
void CDDM_recalc_looptri(struct DerivedMesh *dm);
|
|
|
|
|
|
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
|
|
|
/* lowers the number of vertices/edges/faces in a CDDerivedMesh
|
|
|
|
|
* the layer data stays the same size
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
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
|
|
|
void CDDM_lower_num_verts(struct DerivedMesh *dm, int numVerts);
|
|
|
|
|
void CDDM_lower_num_edges(struct DerivedMesh *dm, int numEdges);
|
2013-11-04 12:01:46 +00:00
|
|
|
void CDDM_lower_num_loops(struct DerivedMesh *dm, int numLoops);
|
2011-12-31 12:58:03 +00:00
|
|
|
void CDDM_lower_num_polys(struct DerivedMesh *dm, int numPolys);
|
|
|
|
|
void CDDM_lower_num_tessfaces(DerivedMesh *dm, int numTessFaces);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
/* vertex/edge/face access functions
|
|
|
|
|
* should always succeed if index is within bounds
|
|
|
|
|
* note these return pointers - any change modifies the internals of the mesh
|
|
|
|
|
*/
|
|
|
|
|
struct MVert *CDDM_get_vert(struct DerivedMesh *dm, int index);
|
|
|
|
|
struct MEdge *CDDM_get_edge(struct DerivedMesh *dm, int index);
|
(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
|
|
|
struct MFace *CDDM_get_tessface(struct DerivedMesh *dm, int index);
|
|
|
|
|
struct MLoop *CDDM_get_loop(struct DerivedMesh *dm, int index);
|
2012-02-07 01:13:04 +00:00
|
|
|
struct MPoly *CDDM_get_poly(struct DerivedMesh *dm, int index);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
/* vertex/edge/face array access functions - return the array holding the
|
|
|
|
|
* desired data
|
|
|
|
|
* should always succeed
|
|
|
|
|
* note these return pointers - any change modifies the internals of the mesh
|
|
|
|
|
*/
|
|
|
|
|
struct MVert *CDDM_get_verts(struct DerivedMesh *dm);
|
|
|
|
|
struct MEdge *CDDM_get_edges(struct DerivedMesh *dm);
|
(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
|
|
|
struct MFace *CDDM_get_tessfaces(struct DerivedMesh *dm);
|
|
|
|
|
struct MLoop *CDDM_get_loops(struct DerivedMesh *dm);
|
2011-02-27 06:19:40 +00:00
|
|
|
struct MPoly *CDDM_get_polys(struct DerivedMesh *dm);
|
(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-03 20:19:11 +00:00
|
|
|
/* Assigns news m*** layers to the cddm. Note that you must handle
|
|
|
|
|
* freeing the old ones yourself. Also you must ensure dm->num****Data
|
|
|
|
|
* is correct.*/
|
2009-09-11 10:21:54 +00:00
|
|
|
void CDDM_set_mvert(struct DerivedMesh *dm, struct MVert *mvert);
|
|
|
|
|
void CDDM_set_medge(struct DerivedMesh *dm, struct MEdge *medge);
|
|
|
|
|
void CDDM_set_mface(struct DerivedMesh *dm, struct MFace *mface);
|
|
|
|
|
void CDDM_set_mloop(struct DerivedMesh *dm, struct MLoop *mloop);
|
|
|
|
|
void CDDM_set_mpoly(struct DerivedMesh *dm, struct MPoly *mpoly);
|
|
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
#endif
|
