2012-05-06 17:22:54 +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.
|
|
|
|
|
* Implementation of CDDerivedMesh.
|
|
|
|
|
*
|
|
|
|
|
* BKE_cdderivedmesh.h contains the function prototypes for this file.
|
|
|
|
|
*/
|
2011-02-27 20:40:57 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup bke
|
2011-02-27 20:40:57 +00:00
|
|
|
*/
|
2011-10-10 09:38:02 +00:00
|
|
|
|
2017-09-25 09:56:02 +02:00
|
|
|
#include "atomic_ops.h"
|
|
|
|
|
|
2009-11-10 20:43:45 +00:00
|
|
|
#include "BLI_math.h"
|
2011-01-07 18:36:47 +00:00
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
|
2012-12-15 15:59:25 +00:00
|
|
|
#include "BKE_pbvh.h"
|
2011-01-07 18:36:47 +00:00
|
|
|
#include "BKE_cdderivedmesh.h"
|
|
|
|
|
#include "BKE_mesh.h"
|
2013-12-12 16:26:11 +11:00
|
|
|
#include "BKE_mesh_mapping.h"
|
2018-06-04 15:49:11 +02:00
|
|
|
#include "BKE_object.h"
|
2011-01-07 18:36:47 +00:00
|
|
|
#include "BKE_paint.h"
|
2013-04-13 20:31:52 +00:00
|
|
|
#include "BKE_editmesh.h"
|
2012-07-31 13:43:26 +00:00
|
|
|
#include "BKE_curve.h"
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2012-02-19 22:17:30 +00:00
|
|
|
#include "DNA_mesh_types.h"
|
2006-08-28 01:12:36 +00:00
|
|
|
#include "DNA_meshdata_types.h"
|
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
|
|
|
#include "DNA_object_types.h"
|
2010-03-08 13:49:13 +00:00
|
|
|
#include "DNA_curve_types.h" /* for Curve */
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <limits.h>
|
2009-01-06 18:59:03 +00:00
|
|
|
#include <math.h>
|
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
|
|
|
typedef struct {
|
2019-04-17 06:17:24 +02:00
|
|
|
DerivedMesh dm;
|
|
|
|
|
|
|
|
|
|
/* these point to data in the DerivedMesh custom data layers,
|
|
|
|
|
* they are only here for efficiency and convenience */
|
|
|
|
|
MVert *mvert;
|
|
|
|
|
MEdge *medge;
|
|
|
|
|
MFace *mface;
|
|
|
|
|
MLoop *mloop;
|
|
|
|
|
MPoly *mpoly;
|
|
|
|
|
|
|
|
|
|
/* Cached */
|
|
|
|
|
struct PBVH *pbvh;
|
|
|
|
|
bool pbvh_draw;
|
|
|
|
|
|
|
|
|
|
/* Mesh connectivity */
|
|
|
|
|
MeshElemMap *pmap;
|
|
|
|
|
int *pmap_mem;
|
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
|
|
|
} CDDerivedMesh;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
/**************** DerivedMesh interface functions ****************/
|
|
|
|
|
static int cdDM_getNumVerts(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm->numVertData;
|
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
|
|
|
static int cdDM_getNumEdges(DerivedMesh *dm)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm->numEdgeData;
|
2006-08-28 01:12:36 +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
|
|
|
static int cdDM_getNumTessFaces(DerivedMesh *dm)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
/* uncomment and add a breakpoint on the printf()
|
|
|
|
|
* to help debug tessfaces issues since BMESH merge. */
|
2012-02-27 09:37:59 +00:00
|
|
|
#if 0
|
2019-04-17 06:17:24 +02:00
|
|
|
if (dm->numTessFaceData == 0 && dm->numPolyData != 0) {
|
|
|
|
|
printf("%s: has no faces!\n");
|
|
|
|
|
}
|
2012-02-27 09:37:59 +00:00
|
|
|
#endif
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm->numTessFaceData;
|
2011-11-30 18:03:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int cdDM_getNumLoops(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm->numLoopData;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2011-11-29 13:01:51 +00:00
|
|
|
static int cdDM_getNumPolys(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
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm->numPolyData;
|
(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
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_getVert(DerivedMesh *dm, int index, MVert *r_vert)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
*r_vert = cddm->mvert[index];
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_getEdge(DerivedMesh *dm, int index, MEdge *r_edge)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
*r_edge = cddm->medge[index];
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_getTessFace(DerivedMesh *dm, int index, MFace *r_face)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
*r_face = cddm->mface[index];
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_copyVertArray(DerivedMesh *dm, MVert *r_vert)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(r_vert, cddm->mvert, sizeof(*r_vert) * dm->numVertData);
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_copyEdgeArray(DerivedMesh *dm, MEdge *r_edge)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(r_edge, cddm->medge, sizeof(*r_edge) * dm->numEdgeData);
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_copyTessFaceArray(DerivedMesh *dm, MFace *r_face)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(r_face, cddm->mface, sizeof(*r_face) * dm->numTessFaceData);
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_copyLoopArray(DerivedMesh *dm, MLoop *r_loop)
|
2011-06-14 03:16:08 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(r_loop, cddm->mloop, sizeof(*r_loop) * dm->numLoopData);
|
2011-06-14 03:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_copyPolyArray(DerivedMesh *dm, MPoly *r_poly)
|
2011-06-14 03:16:08 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(r_poly, cddm->mpoly, sizeof(*r_poly) * dm->numPolyData);
|
2011-06-14 03:16:08 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_getMinMax(DerivedMesh *dm, float r_min[3], float r_max[3])
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
int i;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
if (dm->numVertData) {
|
|
|
|
|
for (i = 0; i < dm->numVertData; i++) {
|
|
|
|
|
minmax_v3v3_v3(r_min, r_max, cddm->mvert[i].co);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
zero_v3(r_min);
|
|
|
|
|
zero_v3(r_max);
|
|
|
|
|
}
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_getVertCo(DerivedMesh *dm, int index, float r_co[3])
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
copy_v3_v3(r_co, cddm->mvert[index].co);
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-03-16 03:24:05 +11:00
|
|
|
static void cdDM_getVertNo(DerivedMesh *dm, int index, float r_no[3])
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
normal_short_to_float_v3(r_no, cddm->mvert[index].no);
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-17 10:23:44 +00:00
|
|
|
static const MeshElemMap *cdDM_getPolyMap(Object *ob, DerivedMesh *dm)
|
2012-02-05 06:20:51 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2012-02-05 06:20:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
if (!cddm->pmap && ob->type == OB_MESH) {
|
|
|
|
|
Mesh *me = ob->data;
|
2012-02-05 06:20:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
BKE_mesh_vert_poly_map_create(
|
|
|
|
|
&cddm->pmap, &cddm->pmap_mem, me->mpoly, me->mloop, me->totvert, me->totpoly, me->totloop);
|
|
|
|
|
}
|
2012-02-05 06:20:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
return cddm->pmap;
|
2012-02-05 06:20:51 +00:00
|
|
|
}
|
|
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
void CDDM_recalc_looptri(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
const unsigned int totpoly = dm->numPolyData;
|
|
|
|
|
const unsigned int totloop = dm->numLoopData;
|
2015-07-17 03:36:03 +10:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
DM_ensure_looptri_data(dm);
|
|
|
|
|
BLI_assert(totpoly == 0 || cddm->dm.looptris.array_wip != NULL);
|
2015-07-17 03:36:03 +10:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
BKE_mesh_recalc_looptri(
|
|
|
|
|
cddm->mloop, cddm->mpoly, cddm->mvert, totloop, totpoly, cddm->dm.looptris.array_wip);
|
2017-09-19 13:57:46 +02:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
BLI_assert(cddm->dm.looptris.array == NULL);
|
|
|
|
|
atomic_cas_ptr(
|
|
|
|
|
(void **)&cddm->dm.looptris.array, cddm->dm.looptris.array, cddm->dm.looptris.array_wip);
|
|
|
|
|
cddm->dm.looptris.array_wip = NULL;
|
2015-07-17 03:36:03 +10:00
|
|
|
}
|
|
|
|
|
|
2009-10-28 06:06:05 +00:00
|
|
|
static void cdDM_free_internal(CDDerivedMesh *cddm)
|
|
|
|
|
{
|
2019-04-22 09:39:35 +10:00
|
|
|
if (cddm->pmap) {
|
2019-04-17 06:17:24 +02:00
|
|
|
MEM_freeN(cddm->pmap);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
|
|
|
|
if (cddm->pmap_mem) {
|
2019-04-17 06:17:24 +02:00
|
|
|
MEM_freeN(cddm->pmap_mem);
|
2019-04-22 09:39:35 +10:00
|
|
|
}
|
2009-10-28 06:06:05 +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
|
|
|
static void cdDM_release(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
if (DM_release(dm)) {
|
|
|
|
|
cdDM_free_internal(cddm);
|
|
|
|
|
MEM_freeN(cddm);
|
|
|
|
|
}
|
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
|
|
|
}
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
/**************** CDDM interface functions ****************/
|
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
|
|
|
static CDDerivedMesh *cdDM_create(const char *desc)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm;
|
|
|
|
|
DerivedMesh *dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
cddm = MEM_callocN(sizeof(*cddm), desc);
|
|
|
|
|
dm = &cddm->dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->getMinMax = cdDM_getMinMax;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->getNumVerts = cdDM_getNumVerts;
|
|
|
|
|
dm->getNumEdges = cdDM_getNumEdges;
|
|
|
|
|
dm->getNumTessFaces = cdDM_getNumTessFaces;
|
|
|
|
|
dm->getNumLoops = cdDM_getNumLoops;
|
|
|
|
|
dm->getNumPolys = cdDM_getNumPolys;
|
(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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->getVert = cdDM_getVert;
|
|
|
|
|
dm->getEdge = cdDM_getEdge;
|
|
|
|
|
dm->getTessFace = cdDM_getTessFace;
|
2011-11-29 13:01:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->copyVertArray = cdDM_copyVertArray;
|
|
|
|
|
dm->copyEdgeArray = cdDM_copyEdgeArray;
|
|
|
|
|
dm->copyTessFaceArray = cdDM_copyTessFaceArray;
|
|
|
|
|
dm->copyLoopArray = cdDM_copyLoopArray;
|
|
|
|
|
dm->copyPolyArray = cdDM_copyPolyArray;
|
2011-11-13 15:13:59 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->getVertData = DM_get_vert_data;
|
|
|
|
|
dm->getEdgeData = DM_get_edge_data;
|
|
|
|
|
dm->getTessFaceData = DM_get_tessface_data;
|
|
|
|
|
dm->getVertDataArray = DM_get_vert_data_layer;
|
|
|
|
|
dm->getEdgeDataArray = DM_get_edge_data_layer;
|
|
|
|
|
dm->getTessFaceDataArray = DM_get_tessface_data_layer;
|
2011-11-29 13:01:51 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->recalcLoopTri = CDDM_recalc_looptri;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->getVertCo = cdDM_getVertCo;
|
|
|
|
|
dm->getVertNo = cdDM_getVertNo;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->getPolyMap = cdDM_getPolyMap;
|
2009-10-28 06:06:05 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
dm->release = cdDM_release;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
return cddm;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2011-11-30 18:03:56 +00:00
|
|
|
DerivedMesh *CDDM_new(int numVerts, int numEdges, int numTessFaces, int numLoops, int numPolys)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_new dm");
|
|
|
|
|
DerivedMesh *dm = &cddm->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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
DM_init(dm, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces, numLoops, numPolys);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_ORIGINDEX, CD_CALLOC, NULL, numVerts);
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
|
|
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
|
|
|
|
|
CustomData_add_layer(&dm->polyData, CD_ORIGINDEX, CD_CALLOC, NULL, numPolys);
|
2008-06-09 17:22:38 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_CALLOC, NULL, numVerts);
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
|
|
|
|
|
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_CALLOC, NULL, numTessFaces);
|
|
|
|
|
CustomData_add_layer(&dm->loopData, CD_MLOOP, CD_CALLOC, NULL, numLoops);
|
|
|
|
|
CustomData_add_layer(&dm->polyData, CD_MPOLY, CD_CALLOC, NULL, numPolys);
|
2006-12-12 21:29:09 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
cddm->mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
|
|
|
|
|
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
|
|
|
|
|
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
|
|
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2013-12-26 08:26:41 +11:00
|
|
|
DerivedMesh *CDDM_from_mesh(Mesh *mesh)
|
2018-04-25 15:38:26 +02:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return CDDM_from_mesh_ex(mesh, CD_REFERENCE, &CD_MASK_MESH);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DerivedMesh *CDDM_from_mesh_ex(Mesh *mesh,
|
|
|
|
|
eCDAllocType alloctype,
|
|
|
|
|
const CustomData_MeshMasks *mask)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = cdDM_create(__func__);
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
CustomData_MeshMasks cddata_masks = *mask;
|
|
|
|
|
|
|
|
|
|
cddata_masks.lmask &= ~CD_MASK_MDISPS;
|
|
|
|
|
|
|
|
|
|
/* this does a referenced copy, with an exception for fluidsim */
|
|
|
|
|
|
|
|
|
|
DM_init(dm,
|
|
|
|
|
DM_TYPE_CDDM,
|
|
|
|
|
mesh->totvert,
|
|
|
|
|
mesh->totedge,
|
|
|
|
|
0 /* mesh->totface */,
|
|
|
|
|
mesh->totloop,
|
|
|
|
|
mesh->totpoly);
|
|
|
|
|
|
|
|
|
|
/* This should actually be dm->deformedOnly = mesh->runtime.deformed_only,
|
|
|
|
|
* but only if the original mesh had its deformed_only flag correctly set
|
|
|
|
|
* (which isn't generally the case). */
|
|
|
|
|
dm->deformedOnly = 1;
|
|
|
|
|
dm->cd_flag = mesh->cd_flag;
|
|
|
|
|
|
|
|
|
|
if (mesh->runtime.cd_dirty_vert & CD_MASK_NORMAL) {
|
|
|
|
|
dm->dirty |= DM_DIRTY_NORMALS;
|
|
|
|
|
}
|
2019-04-27 12:07:07 +10:00
|
|
|
/* TODO DM_DIRTY_TESS_CDLAYERS ? Maybe not though,
|
|
|
|
|
* since we probably want to switch to looptris? */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
|
|
|
|
CustomData_merge(&mesh->vdata, &dm->vertData, cddata_masks.vmask, alloctype, mesh->totvert);
|
|
|
|
|
CustomData_merge(&mesh->edata, &dm->edgeData, cddata_masks.emask, alloctype, mesh->totedge);
|
|
|
|
|
CustomData_merge(&mesh->fdata,
|
|
|
|
|
&dm->faceData,
|
|
|
|
|
cddata_masks.fmask | CD_MASK_ORIGINDEX,
|
|
|
|
|
alloctype,
|
|
|
|
|
0 /* mesh->totface */);
|
|
|
|
|
CustomData_merge(&mesh->ldata, &dm->loopData, cddata_masks.lmask, alloctype, mesh->totloop);
|
|
|
|
|
CustomData_merge(&mesh->pdata, &dm->polyData, cddata_masks.pmask, alloctype, mesh->totpoly);
|
|
|
|
|
|
|
|
|
|
cddm->mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
|
|
|
|
|
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
|
|
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
2015-07-31 11:52:21 +10:00
|
|
|
#if 0
|
2019-04-17 06:17:24 +02:00
|
|
|
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
|
2015-07-31 11:52:21 +10:00
|
|
|
#else
|
2019-04-17 06:17:24 +02:00
|
|
|
cddm->mface = NULL;
|
2015-07-31 11:52:21 +10:00
|
|
|
#endif
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* commented since even when CD_ORIGINDEX was first added this line fails
|
|
|
|
|
* on the default cube, (after editmode toggle too) - campbell */
|
2011-11-23 16:39:07 +00:00
|
|
|
#if 0
|
2019-04-17 06:17:24 +02:00
|
|
|
BLI_assert(CustomData_has_layer(&cddm->dm.faceData, CD_ORIGINDEX));
|
2011-11-23 16:39:07 +00:00
|
|
|
#endif
|
2011-11-13 15:13:59 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2018-10-15 18:11:37 +11:00
|
|
|
DerivedMesh *CDDM_copy(DerivedMesh *source)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_copy cddm");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
int numVerts = source->numVertData;
|
|
|
|
|
int numEdges = source->numEdgeData;
|
|
|
|
|
int numTessFaces = 0;
|
|
|
|
|
int numLoops = source->numLoopData;
|
|
|
|
|
int numPolys = source->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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* NOTE: Don't copy tessellation faces if not requested explicitly. */
|
2017-02-02 14:32:05 +01:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* ensure these are created if they are made on demand */
|
|
|
|
|
source->getVertDataArray(source, CD_ORIGINDEX);
|
|
|
|
|
source->getEdgeDataArray(source, CD_ORIGINDEX);
|
|
|
|
|
source->getPolyDataArray(source, CD_ORIGINDEX);
|
2009-11-25 13:11:44 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* this initializes dm, and copies all non mvert/medge/mface layers */
|
|
|
|
|
DM_from_template(dm, source, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces, numLoops, numPolys);
|
|
|
|
|
dm->deformedOnly = source->deformedOnly;
|
|
|
|
|
dm->cd_flag = source->cd_flag;
|
|
|
|
|
dm->dirty = source->dirty;
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* Tessellation data is never copied, so tag it here.
|
|
|
|
|
* Only tag dirty layers if we really ignored tessellation faces.
|
|
|
|
|
*/
|
|
|
|
|
dm->dirty |= DM_DIRTY_TESS_CDLAYERS;
|
2017-02-02 14:32:05 +01:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
CustomData_copy_data(&source->vertData, &dm->vertData, 0, 0, numVerts);
|
|
|
|
|
CustomData_copy_data(&source->edgeData, &dm->edgeData, 0, 0, numEdges);
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
/* now add mvert/medge/mface layers */
|
|
|
|
|
cddm->mvert = source->dupVertArray(source);
|
|
|
|
|
cddm->medge = source->dupEdgeArray(source);
|
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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_ASSIGN, cddm->mvert, numVerts);
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_ASSIGN, cddm->medge, numEdges);
|
2017-02-02 14:32:05 +01:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
DM_DupPolys(source, 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
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
2011-11-13 15:13:59 +00:00
|
|
|
|
2019-04-17 06:17:24 +02:00
|
|
|
return dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
/* #define DEBUG_CLNORS */
|
2016-06-07 13:04:05 +02:00
|
|
|
#ifdef DEBUG_CLNORS
|
|
|
|
|
# include "BLI_linklist.h"
|
|
|
|
|
#endif
|
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
|
|
|
|
2012-02-07 01:13:04 +00:00
|
|
|
/* mesh element access functions */
|
|
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
MVert *CDDM_get_vert(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return &((CDDerivedMesh *)dm)->mvert[index];
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEdge *CDDM_get_edge(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return &((CDDerivedMesh *)dm)->medge[index];
|
2006-08-28 01:12:36 +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
|
|
|
MFace *CDDM_get_tessface(DerivedMesh *dm, int index)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return &((CDDerivedMesh *)dm)->mface[index];
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2012-02-07 01:13:04 +00:00
|
|
|
MLoop *CDDM_get_loop(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return &((CDDerivedMesh *)dm)->mloop[index];
|
2012-02-07 01:13:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MPoly *CDDM_get_poly(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return &((CDDerivedMesh *)dm)->mpoly[index];
|
2012-02-07 01:13:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* array access functions */
|
|
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
MVert *CDDM_get_verts(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return ((CDDerivedMesh *)dm)->mvert;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEdge *CDDM_get_edges(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return ((CDDerivedMesh *)dm)->medge;
|
2006-08-28 01:12:36 +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
|
|
|
MFace *CDDM_get_tessfaces(DerivedMesh *dm)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return ((CDDerivedMesh *)dm)->mface;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2011-02-27 07:49:36 +00:00
|
|
|
MLoop *CDDM_get_loops(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return ((CDDerivedMesh *)dm)->mloop;
|
2011-02-27 07:49:36 +00:00
|
|
|
}
|
|
|
|
|
|
2011-02-27 06:19:40 +00:00
|
|
|
MPoly *CDDM_get_polys(DerivedMesh *dm)
|
|
|
|
|
{
|
2019-04-17 06:17:24 +02:00
|
|
|
return ((CDDerivedMesh *)dm)->mpoly;
|
2011-02-27 06:19:40 +00:00
|
|
|
}
|
