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 {
|
|
|
|
|
DerivedMesh dm;
|
|
|
|
|
|
|
|
|
|
/* these point to data in the DerivedMesh custom data layers,
|
2012-03-09 18:28:30 +00:00
|
|
|
* they are only here for efficiency and convenience **/
|
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
|
|
|
MVert *mvert;
|
|
|
|
|
MEdge *medge;
|
|
|
|
|
MFace *mface;
|
(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
|
|
|
MLoop *mloop;
|
|
|
|
|
MPoly *mpoly;
|
2009-10-28 06:06:05 +00:00
|
|
|
|
|
|
|
|
/* Cached */
|
|
|
|
|
struct PBVH *pbvh;
|
2014-04-01 11:34:00 +11:00
|
|
|
bool pbvh_draw;
|
2011-01-31 20:02:51 +00:00
|
|
|
|
2009-10-28 06:06:05 +00:00
|
|
|
/* Mesh connectivity */
|
2012-03-17 04:41:36 +00:00
|
|
|
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)
|
|
|
|
|
{
|
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
|
|
|
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
|
|
|
{
|
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
|
|
|
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
|
|
|
{
|
2012-02-27 09:37:59 +00:00
|
|
|
/* uncomment and add a breakpoint on the printf()
|
|
|
|
|
* to help debug tessfaces issues since BMESH merge. */
|
|
|
|
|
#if 0
|
|
|
|
|
if (dm->numTessFaceData == 0 && dm->numPolyData != 0) {
|
2018-10-15 17:37:54 +11:00
|
|
|
printf("%s: has no faces!\n");
|
2012-02-27 09:37:59 +00:00
|
|
|
}
|
|
|
|
|
#endif
|
2011-11-30 18:03:56 +00:00
|
|
|
return dm->numTessFaceData;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int cdDM_getNumLoops(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
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
|
|
|
{
|
|
|
|
|
return dm->numPolyData;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
{
|
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 *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
*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
|
|
|
{
|
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 *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
*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
|
|
|
{
|
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 *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
*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
|
|
|
{
|
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 *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
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 *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
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 *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
int i;
|
|
|
|
|
|
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 (dm->numVertData) {
|
2012-05-01 12:51:17 +00:00
|
|
|
for (i = 0; i < dm->numVertData; i++) {
|
2014-03-16 03:24:05 +11:00
|
|
|
minmax_v3v3_v3(r_min, r_max, cddm->mvert[i].co);
|
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
|
|
|
}
|
2012-03-23 20:18:09 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
|
2014-03-16 03:24:05 +11: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_getVertCos(DerivedMesh *dm, float (*r_cos)[3])
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
|
|
|
|
MVert *mv = CDDM_get_verts(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
|
|
|
int i;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (i = 0; i < dm->numVertData; i++, mv++)
|
2014-03-16 03:24:05 +11:00
|
|
|
copy_v3_v3(r_cos[i], mv->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
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
|
2014-03-16 03:24:05 +11:00
|
|
|
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
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
|
2012-02-05 06:20:51 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!cddm->pmap && ob->type == OB_MESH) {
|
2012-05-06 17:22:54 +00:00
|
|
|
Mesh *me = ob->data;
|
2012-02-05 06:20:51 +00:00
|
|
|
|
2015-07-15 12:08:32 +10: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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return cddm->pmap;
|
|
|
|
|
}
|
|
|
|
|
|
2014-05-06 16:55:50 +02:00
|
|
|
static bool check_sculpt_object_deformed(Object *object, bool for_construction)
|
2010-06-21 20:10:59 +00:00
|
|
|
{
|
2014-05-06 14:49:50 +02:00
|
|
|
bool deformed = false;
|
2010-06-21 20:10:59 +00:00
|
|
|
|
2014-05-06 14:49:50 +02:00
|
|
|
/* Active modifiers means extra deformation, which can't be handled correct
|
2012-04-25 06:06:40 +00:00
|
|
|
* on birth of PBVH and sculpt "layer" levels, so use PBVH only for internal brush
|
2014-05-06 14:49:50 +02:00
|
|
|
* stuff and show final DerivedMesh so user would see actual object shape.
|
|
|
|
|
*/
|
|
|
|
|
deformed |= object->sculpt->modifiers_active;
|
2011-04-23 09:07:46 +00:00
|
|
|
|
2014-05-06 16:55:50 +02:00
|
|
|
if (for_construction) {
|
|
|
|
|
deformed |= object->sculpt->kb != NULL;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* As in case with modifiers, we can't synchronize deformation made against
|
|
|
|
|
* PBVH and non-locked keyblock, so also use PBVH only for brushes and
|
|
|
|
|
* final DM to give final result to user.
|
|
|
|
|
*/
|
|
|
|
|
deformed |= object->sculpt->kb && (object->shapeflag & OB_SHAPE_LOCK) == 0;
|
|
|
|
|
}
|
2010-06-21 20:10:59 +00:00
|
|
|
|
2014-05-06 14:49:50 +02:00
|
|
|
return deformed;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static bool can_pbvh_draw(Object *ob, DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
|
|
|
|
|
Mesh *me = ob->data;
|
2014-05-06 16:55:50 +02:00
|
|
|
bool deformed = check_sculpt_object_deformed(ob, false);
|
2014-05-06 14:49:50 +02:00
|
|
|
|
|
|
|
|
if (deformed) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2010-06-21 20:10:59 +00:00
|
|
|
|
2011-09-07 12:47:23 +00:00
|
|
|
return cddm->mvert == me->mvert || ob->sculpt->kb;
|
2010-06-21 20:10:59 +00:00
|
|
|
}
|
|
|
|
|
|
2018-04-05 18:20:27 +02:00
|
|
|
static PBVH *cdDM_getPBVH(Object *ob, DerivedMesh *dm)
|
2009-10-28 06:06:05 +00:00
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
|
2009-10-28 06:06:05 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!ob) {
|
2012-05-06 17:22:54 +00:00
|
|
|
cddm->pbvh = NULL;
|
2010-03-22 11:59:36 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!ob->sculpt)
|
2010-03-22 11:59:36 +00:00
|
|
|
return NULL;
|
2012-05-01 12:51:17 +00:00
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (ob->sculpt->pbvh) {
|
2012-05-06 17:22:54 +00:00
|
|
|
cddm->pbvh = ob->sculpt->pbvh;
|
2010-06-21 20:10:59 +00:00
|
|
|
cddm->pbvh_draw = can_pbvh_draw(ob, dm);
|
2010-06-02 18:04:31 +00:00
|
|
|
}
|
2009-11-25 13:11:44 +00:00
|
|
|
|
2012-12-30 18:29:41 +00:00
|
|
|
/* Sculpting on a BMesh (dynamic-topology) gets a special PBVH */
|
|
|
|
|
if (!cddm->pbvh && ob->sculpt->bm) {
|
2012-12-30 18:31:31 +00:00
|
|
|
cddm->pbvh = BKE_pbvh_new();
|
2014-04-01 11:34:00 +11:00
|
|
|
cddm->pbvh_draw = true;
|
2012-12-30 18:29:41 +00:00
|
|
|
|
2012-12-30 18:31:31 +00:00
|
|
|
BKE_pbvh_build_bmesh(cddm->pbvh, ob->sculpt->bm,
|
2013-01-02 01:49:07 +00:00
|
|
|
ob->sculpt->bm_smooth_shading,
|
2014-04-17 19:02:55 +03:00
|
|
|
ob->sculpt->bm_log, ob->sculpt->cd_vert_node_offset,
|
|
|
|
|
ob->sculpt->cd_face_node_offset);
|
2014-04-02 17:33:47 +03:00
|
|
|
|
|
|
|
|
pbvh_show_diffuse_color_set(cddm->pbvh, ob->sculpt->show_diffuse_color);
|
2018-01-15 11:38:56 +01:00
|
|
|
pbvh_show_mask_set(cddm->pbvh, ob->sculpt->show_mask);
|
2012-12-30 18:29:41 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-12-30 18:29:41 +00:00
|
|
|
|
2010-06-02 18:04:31 +00:00
|
|
|
/* always build pbvh from original mesh, and only use it for drawing if
|
2012-03-09 18:28:30 +00:00
|
|
|
* this derivedmesh is just original mesh. it's the multires subsurf dm
|
|
|
|
|
* that this is actually for, to support a pbvh on a modified mesh */
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!cddm->pbvh && ob->type == OB_MESH) {
|
2018-06-04 15:49:11 +02:00
|
|
|
Mesh *me = BKE_object_get_original_mesh(ob);
|
2015-07-17 03:36:03 +10:00
|
|
|
const int looptris_num = poly_to_tri_count(me->totpoly, me->totloop);
|
|
|
|
|
MLoopTri *looptri;
|
2014-05-06 14:49:50 +02:00
|
|
|
bool deformed;
|
2012-05-01 12:14:44 +00:00
|
|
|
|
2012-12-30 18:31:31 +00:00
|
|
|
cddm->pbvh = BKE_pbvh_new();
|
2010-06-21 20:10:59 +00:00
|
|
|
cddm->pbvh_draw = can_pbvh_draw(ob, dm);
|
2012-03-14 06:30:55 +00:00
|
|
|
|
2018-01-14 22:14:20 +01:00
|
|
|
looptri = MEM_malloc_arrayN(looptris_num, sizeof(*looptri), __func__);
|
2015-07-17 03:36:03 +10:00
|
|
|
|
|
|
|
|
BKE_mesh_recalc_looptri(
|
|
|
|
|
me->mloop, me->mpoly,
|
|
|
|
|
me->mvert,
|
|
|
|
|
me->totloop, me->totpoly,
|
|
|
|
|
looptri);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
BKE_pbvh_build_mesh(
|
|
|
|
|
cddm->pbvh,
|
|
|
|
|
me->mpoly, me->mloop,
|
|
|
|
|
me->mvert, me->totvert, &me->vdata,
|
|
|
|
|
looptri, looptris_num);
|
2011-01-31 20:02:51 +00:00
|
|
|
|
2014-05-01 02:11:39 +03:00
|
|
|
pbvh_show_diffuse_color_set(cddm->pbvh, ob->sculpt->show_diffuse_color);
|
2018-01-15 11:38:56 +01:00
|
|
|
pbvh_show_mask_set(cddm->pbvh, ob->sculpt->show_mask);
|
2014-05-01 02:11:39 +03:00
|
|
|
|
2014-05-06 16:55:50 +02:00
|
|
|
deformed = check_sculpt_object_deformed(ob, true);
|
2012-05-01 12:14:44 +00:00
|
|
|
|
|
|
|
|
if (deformed && ob->derivedDeform) {
|
2012-05-01 12:51:17 +00:00
|
|
|
DerivedMesh *deformdm = ob->derivedDeform;
|
2011-01-31 20:02:51 +00:00
|
|
|
float (*vertCos)[3];
|
|
|
|
|
int totvert;
|
|
|
|
|
|
2012-05-01 12:51:17 +00:00
|
|
|
totvert = deformdm->getNumVerts(deformdm);
|
2018-01-14 22:14:20 +01:00
|
|
|
vertCos = MEM_malloc_arrayN(totvert, sizeof(float[3]), "cdDM_getPBVH vertCos");
|
2011-05-04 13:15:42 +00:00
|
|
|
deformdm->getVertCos(deformdm, vertCos);
|
2018-06-08 15:42:37 +02:00
|
|
|
BKE_pbvh_apply_vertCos(cddm->pbvh, vertCos, totvert);
|
2011-01-31 20:02:51 +00:00
|
|
|
MEM_freeN(vertCos);
|
|
|
|
|
}
|
2009-10-28 06:06:05 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return cddm->pbvh;
|
|
|
|
|
}
|
|
|
|
|
|
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_foreachMappedVert(
|
2012-04-09 07:06:06 +00:00
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int index, const float co[3], const float no_f[3], const short no_s[3]),
|
2013-07-22 22:59:47 +00:00
|
|
|
void *userData,
|
|
|
|
|
DMForeachFlag flag)
|
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
|
|
|
MVert *mv = CDDM_get_verts(dm);
|
2014-04-27 00:20:13 +10:00
|
|
|
const int *index = DM_get_vert_data_layer(dm, CD_ORIGINDEX);
|
2013-07-22 22:59:47 +00:00
|
|
|
int i;
|
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
|
|
|
|
2013-07-22 22:59:47 +00:00
|
|
|
if (index) {
|
|
|
|
|
for (i = 0; i < dm->numVertData; i++, mv++) {
|
|
|
|
|
const short *no = (flag & DM_FOREACH_USE_NORMAL) ? mv->no : NULL;
|
|
|
|
|
const int orig = *index++;
|
2012-03-24 06:18:31 +00:00
|
|
|
if (orig == ORIGINDEX_NONE) continue;
|
2013-07-22 22:59:47 +00:00
|
|
|
func(userData, orig, mv->co, NULL, no);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
for (i = 0; i < dm->numVertData; i++, mv++) {
|
|
|
|
|
const short *no = (flag & DM_FOREACH_USE_NORMAL) ? mv->no : NULL;
|
|
|
|
|
func(userData, i, mv->co, NULL, no);
|
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_foreachMappedEdge(
|
2012-04-09 07:06:06 +00:00
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int index, const float v0co[3], const float v1co[3]),
|
|
|
|
|
void *userData)
|
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
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
MVert *mv = cddm->mvert;
|
|
|
|
|
MEdge *med = cddm->medge;
|
|
|
|
|
int i, orig, *index = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
|
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (i = 0; i < dm->numEdgeData; i++, med++) {
|
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 (index) {
|
|
|
|
|
orig = *index++;
|
2012-03-24 06:18:31 +00:00
|
|
|
if (orig == ORIGINDEX_NONE) continue;
|
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
|
|
|
func(userData, orig, mv[med->v1].co, mv[med->v2].co);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
func(userData, i, mv[med->v1].co, mv[med->v2].co);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-04-23 15:18:11 +02:00
|
|
|
static void cdDM_foreachMappedLoop(
|
|
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int vertex_index, int face_index, const float co[3], const float no[3]),
|
|
|
|
|
void *userData,
|
|
|
|
|
DMForeachFlag flag)
|
|
|
|
|
{
|
|
|
|
|
/* We can't use dm->getLoopDataLayout(dm) here, we want to always access dm->loopData, EditDerivedBMesh would
|
|
|
|
|
* return loop data from bmesh itself. */
|
|
|
|
|
const float (*lnors)[3] = (flag & DM_FOREACH_USE_NORMAL) ? DM_get_loop_data_layer(dm, CD_NORMAL) : NULL;
|
|
|
|
|
|
|
|
|
|
const MVert *mv = CDDM_get_verts(dm);
|
|
|
|
|
const MLoop *ml = CDDM_get_loops(dm);
|
|
|
|
|
const MPoly *mp = CDDM_get_polys(dm);
|
|
|
|
|
const int *v_index = DM_get_vert_data_layer(dm, CD_ORIGINDEX);
|
|
|
|
|
const int *f_index = DM_get_poly_data_layer(dm, CD_ORIGINDEX);
|
|
|
|
|
int p_idx, i;
|
|
|
|
|
|
|
|
|
|
for (p_idx = 0; p_idx < dm->numPolyData; ++p_idx, ++mp) {
|
|
|
|
|
for (i = 0; i < mp->totloop; ++i, ++ml) {
|
|
|
|
|
const int v_idx = v_index ? v_index[ml->v] : ml->v;
|
|
|
|
|
const int f_idx = f_index ? f_index[p_idx] : p_idx;
|
|
|
|
|
const float *no = lnors ? *lnors++ : NULL;
|
|
|
|
|
if (!ELEM(ORIGINDEX_NONE, v_idx, f_idx)) {
|
|
|
|
|
func(userData, v_idx, f_idx, mv[ml->v].co, no);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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_foreachMappedFaceCenter(
|
2012-04-09 07:06:06 +00:00
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int index, const float cent[3], const float no[3]),
|
2013-07-22 22:59:47 +00:00
|
|
|
void *userData,
|
|
|
|
|
DMForeachFlag flag)
|
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
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2012-05-23 21:39:39 +00:00
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
MPoly *mp;
|
|
|
|
|
MLoop *ml;
|
2013-07-22 22:59:47 +00:00
|
|
|
int i, orig, *index;
|
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
|
|
|
|
2009-06-16 20:08:40 +00:00
|
|
|
index = CustomData_get_layer(&dm->polyData, CD_ORIGINDEX);
|
2012-04-03 23:40:24 +00:00
|
|
|
mp = cddm->mpoly;
|
|
|
|
|
for (i = 0; i < dm->numPolyData; i++, mp++) {
|
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
|
|
|
float cent[3];
|
2013-07-22 22:59:47 +00:00
|
|
|
float *no, _no[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
|
|
|
|
|
|
|
|
if (index) {
|
|
|
|
|
orig = *index++;
|
2012-03-24 06:18:31 +00:00
|
|
|
if (orig == ORIGINDEX_NONE) continue;
|
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
|
|
|
}
|
2013-07-22 22:59:47 +00:00
|
|
|
else {
|
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
|
|
|
orig = i;
|
2013-07-22 22:59:47 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-04-03 23:40:24 +00:00
|
|
|
ml = &cddm->mloop[mp->loopstart];
|
2013-07-22 22:59:47 +00:00
|
|
|
BKE_mesh_calc_poly_center(mp, ml, mvert, cent);
|
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
|
|
|
|
2013-07-22 22:59:47 +00:00
|
|
|
if (flag & DM_FOREACH_USE_NORMAL) {
|
|
|
|
|
BKE_mesh_calc_poly_normal(mp, ml, mvert, (no = _no));
|
2012-03-24 06:18:31 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2013-07-22 22:59:47 +00:00
|
|
|
no = NULL;
|
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
|
|
|
|
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
|
|
|
func(userData, orig, cent, no);
|
|
|
|
|
}
|
2009-06-16 20:08:40 +00:00
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2014-01-23 14:50:50 +01:00
|
|
|
void CDDM_recalc_tessellation_ex(DerivedMesh *dm, const bool do_face_nor_cpy)
|
2009-08-28 09:36:31 +00:00
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2009-08-28 09:36:31 +00:00
|
|
|
|
2015-07-15 12:08:32 +10:00
|
|
|
dm->numTessFaceData = BKE_mesh_recalc_tessellation(
|
|
|
|
|
&dm->faceData, &dm->loopData, &dm->polyData,
|
|
|
|
|
cddm->mvert,
|
|
|
|
|
dm->numTessFaceData, dm->numLoopData, dm->numPolyData,
|
|
|
|
|
do_face_nor_cpy);
|
2011-11-23 20:44:04 +00:00
|
|
|
|
2009-11-03 05:06:04 +00:00
|
|
|
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
|
2011-12-01 09:49:27 +00:00
|
|
|
|
2012-03-02 16:05:54 +00:00
|
|
|
/* Tessellation recreated faceData, and the active layer indices need to get re-propagated
|
2012-03-09 18:28:30 +00:00
|
|
|
* from loops and polys to faces */
|
2017-05-25 15:11:00 +10:00
|
|
|
CustomData_bmesh_update_active_layers(&dm->faceData, &dm->loopData);
|
2009-11-03 05:06:04 +00:00
|
|
|
}
|
|
|
|
|
|
2012-03-02 16:05:54 +00:00
|
|
|
void CDDM_recalc_tessellation(DerivedMesh *dm)
|
2012-01-19 19:23:25 +00:00
|
|
|
{
|
2014-01-23 14:50:50 +01:00
|
|
|
CDDM_recalc_tessellation_ex(dm, true);
|
2012-01-19 19:23:25 +00:00
|
|
|
}
|
|
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
void CDDM_recalc_looptri(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
const unsigned int totpoly = dm->numPolyData;
|
|
|
|
|
const unsigned int totloop = dm->numLoopData;
|
|
|
|
|
|
|
|
|
|
DM_ensure_looptri_data(dm);
|
2017-09-20 20:45:51 +02:00
|
|
|
BLI_assert(totpoly == 0 || cddm->dm.looptris.array_wip != NULL);
|
2015-07-17 03:36:03 +10:00
|
|
|
|
|
|
|
|
BKE_mesh_recalc_looptri(
|
|
|
|
|
cddm->mloop, cddm->mpoly,
|
|
|
|
|
cddm->mvert,
|
|
|
|
|
totloop, totpoly,
|
2017-09-19 13:57:46 +02:00
|
|
|
cddm->dm.looptris.array_wip);
|
|
|
|
|
|
|
|
|
|
BLI_assert(cddm->dm.looptris.array == NULL);
|
2017-09-25 10:40:50 +02:00
|
|
|
atomic_cas_ptr((void **)&cddm->dm.looptris.array, cddm->dm.looptris.array, cddm->dm.looptris.array_wip);
|
2017-09-25 09:56:02 +02:00
|
|
|
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)
|
|
|
|
|
{
|
2012-03-24 06:18:31 +00:00
|
|
|
if (cddm->pmap) MEM_freeN(cddm->pmap);
|
|
|
|
|
if (cddm->pmap_mem) MEM_freeN(cddm->pmap_mem);
|
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)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
|
2009-10-28 06:06:05 +00:00
|
|
|
if (DM_release(dm)) {
|
|
|
|
|
cdDM_free_internal(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
|
|
|
MEM_freeN(cddm);
|
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
|
|
|
}
|
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
|
|
|
{
|
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 *cddm;
|
2006-08-28 01:12:36 +00:00
|
|
|
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
|
|
|
cddm = MEM_callocN(sizeof(*cddm), desc);
|
|
|
|
|
dm = &cddm->dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
dm->getMinMax = cdDM_getMinMax;
|
|
|
|
|
|
|
|
|
|
dm->getNumVerts = cdDM_getNumVerts;
|
|
|
|
|
dm->getNumEdges = cdDM_getNumEdges;
|
(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
|
|
|
dm->getNumTessFaces = cdDM_getNumTessFaces;
|
2011-11-30 18:03:56 +00:00
|
|
|
dm->getNumLoops = cdDM_getNumLoops;
|
2011-11-29 13:01:51 +00:00
|
|
|
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
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
dm->getVert = cdDM_getVert;
|
|
|
|
|
dm->getEdge = cdDM_getEdge;
|
2011-11-29 13:01:51 +00:00
|
|
|
dm->getTessFace = cdDM_getTessFace;
|
|
|
|
|
|
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
|
|
|
dm->copyVertArray = cdDM_copyVertArray;
|
|
|
|
|
dm->copyEdgeArray = cdDM_copyEdgeArray;
|
2011-11-29 13:01:51 +00:00
|
|
|
dm->copyTessFaceArray = cdDM_copyTessFaceArray;
|
2011-06-14 03:16:08 +00:00
|
|
|
dm->copyLoopArray = cdDM_copyLoopArray;
|
|
|
|
|
dm->copyPolyArray = cdDM_copyPolyArray;
|
2011-11-13 15:13:59 +00:00
|
|
|
|
2011-11-29 13:01:51 +00: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;
|
|
|
|
|
|
2013-05-30 18:09:19 +00:00
|
|
|
dm->calcNormals = CDDM_calc_normals;
|
2014-04-13 12:18:51 +02:00
|
|
|
dm->calcLoopNormals = CDDM_calc_loop_normals;
|
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
|
|
|
dm->calcLoopNormalsSpaceArray = CDDM_calc_loop_normals_spacearr;
|
2015-08-24 15:14:34 +10:00
|
|
|
dm->calcLoopTangents = DM_calc_loop_tangents;
|
2012-03-02 16:05:54 +00:00
|
|
|
dm->recalcTessellation = CDDM_recalc_tessellation;
|
2015-07-17 03:36:03 +10:00
|
|
|
dm->recalcLoopTri = CDDM_recalc_looptri;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
dm->getVertCos = cdDM_getVertCos;
|
|
|
|
|
dm->getVertCo = cdDM_getVertCo;
|
|
|
|
|
dm->getVertNo = cdDM_getVertNo;
|
|
|
|
|
|
2009-10-28 06:06:05 +00:00
|
|
|
dm->getPBVH = cdDM_getPBVH;
|
2012-02-05 06:20:51 +00:00
|
|
|
dm->getPolyMap = cdDM_getPolyMap;
|
2009-10-28 06:06:05 +00:00
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
dm->foreachMappedVert = cdDM_foreachMappedVert;
|
|
|
|
|
dm->foreachMappedEdge = cdDM_foreachMappedEdge;
|
2014-04-23 15:18:11 +02:00
|
|
|
dm->foreachMappedLoop = cdDM_foreachMappedLoop;
|
2006-08-28 01:12:36 +00:00
|
|
|
dm->foreachMappedFaceCenter = cdDM_foreachMappedFaceCenter;
|
|
|
|
|
|
|
|
|
|
dm->release = cdDM_release;
|
|
|
|
|
|
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
|
|
|
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
|
|
|
{
|
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 *cddm = cdDM_create("CDDM_new dm");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
|
2011-11-30 18:03:56 +00:00
|
|
|
DM_init(dm, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces, numLoops, numPolys);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2008-06-09 17:22:38 +00:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_ORIGINDEX, CD_CALLOC, NULL, numVerts);
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
|
2011-11-30 18:03:56 +00:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
|
(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_add_layer(&dm->polyData, CD_ORIGINDEX, CD_CALLOC, NULL, numPolys);
|
2008-06-09 17:22:38 +00:00
|
|
|
|
2006-12-12 21:29:09 +00:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_CALLOC, NULL, numVerts);
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
|
2011-11-30 18:03:56 +00:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_CALLOC, NULL, numTessFaces);
|
(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_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
|
|
|
|
|
|
|
|
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);
|
(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
|
|
|
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
|
|
|
|
|
|
|
|
return dm;
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-26 08:26:41 +11:00
|
|
|
DerivedMesh *CDDM_from_mesh(Mesh *mesh)
|
2018-04-25 15:38:26 +02: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
|
|
|
return CDDM_from_mesh_ex(mesh, CD_REFERENCE, &CD_MASK_MESH);
|
2018-04-25 15:38:26 +02: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
|
|
|
DerivedMesh *CDDM_from_mesh_ex(Mesh *mesh, eCDAllocType alloctype, const CustomData_MeshMasks *mask)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2013-12-26 08:26:41 +11:00
|
|
|
CDDerivedMesh *cddm = cdDM_create(__func__);
|
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
|
|
|
DerivedMesh *dm = &cddm->dm;
|
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
|
|
|
CustomData_MeshMasks cddata_masks = *mask;
|
2018-05-22 17:53:18 +02: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
|
|
|
cddata_masks.lmask &= ~CD_MASK_MDISPS;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2009-11-04 20:23:48 +00:00
|
|
|
/* this does a referenced copy, with an exception for fluidsim */
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2015-07-31 11:52:21 +10:00
|
|
|
DM_init(dm, DM_TYPE_CDDM, mesh->totvert, mesh->totedge, 0 /* mesh->totface */,
|
2012-05-06 17:22:54 +00:00
|
|
|
mesh->totloop, mesh->totpoly);
|
2008-06-09 17:22:38 +00:00
|
|
|
|
2018-05-16 13:06:54 +02:00
|
|
|
/* 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;
|
2013-01-10 04:43:31 +00:00
|
|
|
dm->cd_flag = mesh->cd_flag;
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2018-05-07 12:24:23 +02:00
|
|
|
if (mesh->runtime.cd_dirty_vert & CD_MASK_NORMAL) {
|
|
|
|
|
dm->dirty |= DM_DIRTY_NORMALS;
|
|
|
|
|
}
|
|
|
|
|
/* TODO DM_DIRTY_TESS_CDLAYERS ? Maybe not though, since we probably want to switch to looptris ? */
|
|
|
|
|
|
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
|
|
|
CustomData_merge(&mesh->vdata, &dm->vertData, cddata_masks.vmask, alloctype,
|
2012-05-06 17:22:54 +00:00
|
|
|
mesh->totvert);
|
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
|
|
|
CustomData_merge(&mesh->edata, &dm->edgeData, cddata_masks.emask, alloctype,
|
2012-05-06 17:22:54 +00:00
|
|
|
mesh->totedge);
|
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
|
|
|
CustomData_merge(&mesh->fdata, &dm->faceData, cddata_masks.fmask | CD_MASK_ORIGINDEX, alloctype,
|
2015-07-31 11:52:21 +10:00
|
|
|
0 /* mesh->totface */);
|
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
|
|
|
CustomData_merge(&mesh->ldata, &dm->loopData, cddata_masks.lmask, alloctype,
|
(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
|
|
|
mesh->totloop);
|
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
|
|
|
CustomData_merge(&mesh->pdata, &dm->polyData, cddata_masks.pmask, alloctype,
|
(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
|
|
|
mesh->totpoly);
|
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
|
|
|
cddm->mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
|
|
|
|
|
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
|
(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
|
|
|
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
|
2009-09-05 06:10:30 +00:00
|
|
|
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
|
2015-07-31 11:52:21 +10:00
|
|
|
#else
|
|
|
|
|
cddm->mface = NULL;
|
|
|
|
|
#endif
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2012-10-30 19:20:17 +00:00
|
|
|
/* commented since even when CD_ORIGINDEX was first added this line fails
|
2011-11-23 16:39:07 +00:00
|
|
|
* on the default cube, (after editmode toggle too) - campbell */
|
|
|
|
|
#if 0
|
2012-10-30 19:20:17 +00: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
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
return dm;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-05 16:47:52 +00:00
|
|
|
DerivedMesh *CDDM_from_curve(Object *ob)
|
2010-03-08 13:49:13 +00:00
|
|
|
{
|
2013-08-19 09:36:40 +00:00
|
|
|
ListBase disp = {NULL, NULL};
|
2013-08-19 09:25:24 +00:00
|
|
|
|
2018-07-30 16:54:40 +02:00
|
|
|
if (ob->runtime.curve_cache) {
|
|
|
|
|
disp = ob->runtime.curve_cache->disp;
|
2013-08-19 09:25:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return CDDM_from_curve_displist(ob, &disp);
|
2010-03-08 13:49:13 +00:00
|
|
|
}
|
|
|
|
|
|
2013-01-10 17:37:17 +00:00
|
|
|
DerivedMesh *CDDM_from_curve_displist(Object *ob, ListBase *dispbase)
|
2012-07-31 13:43:26 +00:00
|
|
|
{
|
2013-06-20 13:27:48 +00:00
|
|
|
Curve *cu = (Curve *) ob->data;
|
2010-03-05 16:47:52 +00:00
|
|
|
DerivedMesh *dm;
|
|
|
|
|
CDDerivedMesh *cddm;
|
|
|
|
|
MVert *allvert;
|
|
|
|
|
MEdge *alledge;
|
2011-04-15 01:19:13 +00:00
|
|
|
MLoop *allloop;
|
|
|
|
|
MPoly *allpoly;
|
2013-06-20 13:27:48 +00:00
|
|
|
MLoopUV *alluv = NULL;
|
2012-02-03 04:58:55 +00:00
|
|
|
int totvert, totedge, totloop, totpoly;
|
2013-06-20 13:27:48 +00:00
|
|
|
bool use_orco_uv = (cu->flag & CU_UV_ORCO) != 0;
|
2010-03-05 16:47:52 +00:00
|
|
|
|
2015-07-15 12:08:32 +10:00
|
|
|
if (BKE_mesh_nurbs_displist_to_mdata(
|
|
|
|
|
ob, dispbase, &allvert, &totvert, &alledge,
|
|
|
|
|
&totedge, &allloop, &allpoly, (use_orco_uv) ? &alluv : NULL,
|
|
|
|
|
&totloop, &totpoly) != 0)
|
2012-05-05 21:28:12 +00:00
|
|
|
{
|
2010-03-05 16:47:52 +00:00
|
|
|
/* Error initializing mdata. This often happens when curve is empty */
|
2010-07-19 04:44:37 +00:00
|
|
|
return CDDM_new(0, 0, 0, 0, 0);
|
2010-03-05 16:47:52 +00:00
|
|
|
}
|
|
|
|
|
|
2012-02-03 04:58:55 +00:00
|
|
|
dm = CDDM_new(totvert, totedge, 0, totloop, totpoly);
|
2010-03-05 16:47:52 +00:00
|
|
|
dm->deformedOnly = 1;
|
2013-05-30 17:36:43 +00:00
|
|
|
dm->dirty |= DM_DIRTY_NORMALS;
|
2010-03-05 16:47:52 +00:00
|
|
|
|
2012-05-06 17:22:54 +00:00
|
|
|
cddm = (CDDerivedMesh *)dm;
|
2010-03-05 16:47:52 +00:00
|
|
|
|
2012-05-06 17:22:54 +00:00
|
|
|
memcpy(cddm->mvert, allvert, totvert * sizeof(MVert));
|
|
|
|
|
memcpy(cddm->medge, alledge, totedge * sizeof(MEdge));
|
|
|
|
|
memcpy(cddm->mloop, allloop, totloop * sizeof(MLoop));
|
|
|
|
|
memcpy(cddm->mpoly, allpoly, totpoly * sizeof(MPoly));
|
2010-03-05 16:47:52 +00:00
|
|
|
|
2013-06-20 13:27:48 +00:00
|
|
|
if (alluv) {
|
|
|
|
|
const char *uvname = "Orco";
|
|
|
|
|
CustomData_add_layer_named(&cddm->dm.loopData, CD_MLOOPUV, CD_ASSIGN, alluv, totloop, uvname);
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-05 16:47:52 +00:00
|
|
|
MEM_freeN(allvert);
|
|
|
|
|
MEM_freeN(alledge);
|
2011-04-15 01:19:13 +00:00
|
|
|
MEM_freeN(allloop);
|
|
|
|
|
MEM_freeN(allpoly);
|
2010-03-05 16:47:52 +00:00
|
|
|
|
|
|
|
|
return dm;
|
|
|
|
|
}
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2015-07-15 12:08:32 +10:00
|
|
|
static void loops_to_customdata_corners(
|
|
|
|
|
BMesh *bm, CustomData *facedata,
|
|
|
|
|
int cdindex, const BMLoop *l3[3],
|
2017-05-25 15:11:00 +10:00
|
|
|
int numCol, int numUV)
|
2009-05-16 16:18:08 +00:00
|
|
|
{
|
2012-10-24 07:24:11 +00:00
|
|
|
const BMLoop *l;
|
2017-05-25 00:34:14 +10:00
|
|
|
// BMFace *f = l3[0]->f;
|
2009-05-16 16:18:08 +00:00
|
|
|
MTFace *texface;
|
|
|
|
|
MCol *mcol;
|
|
|
|
|
MLoopCol *mloopcol;
|
|
|
|
|
MLoopUV *mloopuv;
|
2012-03-22 08:41:50 +00:00
|
|
|
int i, j, hasPCol = CustomData_has_layer(&bm->ldata, CD_PREVIEW_MLOOPCOL);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2017-05-25 15:11:00 +10:00
|
|
|
for (i = 0; i < numUV; i++) {
|
2009-05-16 16:18:08 +00:00
|
|
|
texface = CustomData_get_n(facedata, CD_MTFACE, cdindex, i);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-05-06 17:22:54 +00:00
|
|
|
for (j = 0; j < 3; j++) {
|
2009-05-16 16:18:08 +00:00
|
|
|
l = l3[j];
|
2009-06-23 05:35:49 +00:00
|
|
|
mloopuv = CustomData_bmesh_get_n(&bm->ldata, l->head.data, CD_MLOOPUV, i);
|
2012-02-05 13:25:42 +00:00
|
|
|
copy_v2_v2(texface->uv[j], mloopuv->uv);
|
2009-05-16 16:18:08 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-05-01 12:51:17 +00:00
|
|
|
for (i = 0; i < numCol; i++) {
|
2009-05-16 16:18:08 +00:00
|
|
|
mcol = CustomData_get_n(facedata, CD_MCOL, cdindex, i);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-05-01 12:51:17 +00:00
|
|
|
for (j = 0; j < 3; j++) {
|
2009-05-16 16:18:08 +00:00
|
|
|
l = l3[j];
|
2009-06-23 05:35:49 +00:00
|
|
|
mloopcol = CustomData_bmesh_get_n(&bm->ldata, l->head.data, CD_MLOOPCOL, i);
|
2012-03-17 20:39:28 +00:00
|
|
|
MESH_MLOOPCOL_TO_MCOL(mloopcol, &mcol[j]);
|
2009-05-16 16:18:08 +00:00
|
|
|
}
|
|
|
|
|
}
|
2009-08-31 15:57:13 +00:00
|
|
|
|
2012-03-22 08:41:50 +00:00
|
|
|
if (hasPCol) {
|
|
|
|
|
mcol = CustomData_get(facedata, cdindex, CD_PREVIEW_MCOL);
|
2009-08-31 15:57:13 +00:00
|
|
|
|
2012-05-01 12:51:17 +00:00
|
|
|
for (j = 0; j < 3; j++) {
|
2009-08-31 15:57:13 +00:00
|
|
|
l = l3[j];
|
2012-03-22 08:41:50 +00:00
|
|
|
mloopcol = CustomData_bmesh_get(&bm->ldata, l->head.data, CD_PREVIEW_MLOOPCOL);
|
2012-03-17 20:39:28 +00:00
|
|
|
MESH_MLOOPCOL_TO_MCOL(mloopcol, &mcol[j]);
|
2009-08-31 15:57:13 +00:00
|
|
|
}
|
|
|
|
|
}
|
2009-05-16 16:18:08 +00:00
|
|
|
}
|
|
|
|
|
|
2018-10-10 12:51:14 +11:00
|
|
|
/* TODO(campbell): remove, use BKE_mesh_from_bmesh_for_eval_nomain instead. */
|
|
|
|
|
|
2012-10-24 07:24:11 +00:00
|
|
|
/* used for both editbmesh and bmesh */
|
2015-07-15 12:08:32 +10:00
|
|
|
static DerivedMesh *cddm_from_bmesh_ex(
|
|
|
|
|
struct BMesh *bm, const bool use_mdisps,
|
|
|
|
|
/* EditBMesh vars for use_tessface */
|
|
|
|
|
const bool use_tessface,
|
|
|
|
|
const int em_tottri, const BMLoop *(*em_looptris)[3])
|
2009-05-16 16:18:08 +00:00
|
|
|
{
|
2012-02-07 03:03:09 +00:00
|
|
|
DerivedMesh *dm = CDDM_new(bm->totvert,
|
|
|
|
|
bm->totedge,
|
2012-10-24 07:24:11 +00:00
|
|
|
use_tessface ? em_tottri : 0,
|
2012-02-07 03:03:09 +00:00
|
|
|
bm->totloop,
|
|
|
|
|
bm->totface);
|
|
|
|
|
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2012-12-21 07:28:14 +00:00
|
|
|
BMIter iter;
|
2009-05-16 16:18:08 +00:00
|
|
|
BMVert *eve;
|
|
|
|
|
BMEdge *eed;
|
|
|
|
|
BMFace *efa;
|
|
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
MEdge *medge = cddm->medge;
|
|
|
|
|
MFace *mface = cddm->mface;
|
(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
|
|
|
MLoop *mloop = cddm->mloop;
|
|
|
|
|
MPoly *mpoly = cddm->mpoly;
|
2012-01-18 14:52:47 +00:00
|
|
|
int numCol = CustomData_number_of_layers(&bm->ldata, CD_MLOOPCOL);
|
2017-05-25 15:11:00 +10:00
|
|
|
int numUV = CustomData_number_of_layers(&bm->ldata, CD_MLOOPUV);
|
2012-01-18 15:09:27 +00:00
|
|
|
int *index, add_orig;
|
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
|
|
|
CustomData_MeshMasks mask = {0};
|
2011-12-28 04:43:29 +00:00
|
|
|
unsigned int i, j;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2013-01-10 04:43:31 +00:00
|
|
|
const int cd_vert_bweight_offset = CustomData_get_offset(&bm->vdata, CD_BWEIGHT);
|
|
|
|
|
const int cd_edge_bweight_offset = CustomData_get_offset(&bm->edata, CD_BWEIGHT);
|
|
|
|
|
const int cd_edge_crease_offset = CustomData_get_offset(&bm->edata, CD_CREASE);
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-05-16 16:18:08 +00:00
|
|
|
dm->deformedOnly = 1;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-08-17 14:43:20 +00:00
|
|
|
/* don't add origindex layer if one already exists */
|
2012-01-18 14:52:47 +00:00
|
|
|
add_orig = !CustomData_has_layer(&bm->pdata, CD_ORIGINDEX);
|
2009-05-16 16:18:08 +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
|
|
|
mask = CD_MASK_DERIVEDMESH;
|
|
|
|
|
if (use_mdisps) {
|
|
|
|
|
mask.lmask |= CD_MASK_MDISPS;
|
|
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2012-03-09 18:28:30 +00:00
|
|
|
/* don't process shapekeys, we only feed them through the modifier stack as needed,
|
|
|
|
|
* e.g. for applying modifiers or the like*/
|
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
|
|
|
mask.vmask &= ~CD_MASK_SHAPEKEY;
|
|
|
|
|
CustomData_merge(&bm->vdata, &dm->vertData, mask.vmask,
|
2009-05-16 16:18:08 +00:00
|
|
|
CD_CALLOC, dm->numVertData);
|
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
|
|
|
CustomData_merge(&bm->edata, &dm->edgeData, mask.emask,
|
2009-06-23 05:35:49 +00:00
|
|
|
CD_CALLOC, dm->numEdgeData);
|
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
|
|
|
CustomData_merge(&bm->ldata, &dm->loopData, mask.lmask,
|
(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
|
|
|
CD_CALLOC, dm->numLoopData);
|
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
|
|
|
CustomData_merge(&bm->pdata, &dm->polyData, mask.pmask,
|
(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
|
|
|
CD_CALLOC, dm->numPolyData);
|
2012-12-21 07:28:14 +00:00
|
|
|
|
2012-08-17 14:43:20 +00:00
|
|
|
/* add tessellation mface layers */
|
2012-01-18 15:09:27 +00:00
|
|
|
if (use_tessface) {
|
2017-05-25 15:11:00 +10:00
|
|
|
CustomData_from_bmeshpoly(&dm->faceData, &dm->loopData, em_tottri);
|
2012-01-18 15:09:27 +00:00
|
|
|
}
|
2009-05-16 16:18:08 +00:00
|
|
|
|
|
|
|
|
index = dm->getVertDataArray(dm, CD_ORIGINDEX);
|
|
|
|
|
|
2013-08-01 18:33:35 +00:00
|
|
|
BM_ITER_MESH_INDEX (eve, &iter, bm, BM_VERTS_OF_MESH, i) {
|
2009-05-16 16:18:08 +00:00
|
|
|
MVert *mv = &mvert[i];
|
|
|
|
|
|
2011-11-07 09:02:10 +00:00
|
|
|
copy_v3_v3(mv->co, eve->co);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
BM_elem_index_set(eve, i); /* set_inline */
|
2009-06-23 05:35:49 +00:00
|
|
|
|
2011-10-27 12:17:02 +00:00
|
|
|
normal_float_to_short_v3(mv->no, eve->no);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
mv->flag = BM_vert_flag_to_mflag(eve);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2013-01-10 04:43:31 +00:00
|
|
|
if (cd_vert_bweight_offset != -1) mv->bweight = BM_ELEM_CD_GET_FLOAT_AS_UCHAR(eve, cd_vert_bweight_offset);
|
2011-03-27 03:29:27 +00:00
|
|
|
|
2013-08-01 18:33:35 +00:00
|
|
|
if (add_orig) *index++ = i;
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2009-06-23 05:35:49 +00:00
|
|
|
CustomData_from_bmesh_block(&bm->vdata, &dm->vertData, eve->head.data, i);
|
2009-05-16 16:18:08 +00:00
|
|
|
}
|
2011-11-16 12:38:40 +00:00
|
|
|
bm->elem_index_dirty &= ~BM_VERT;
|
2009-05-16 16:18:08 +00:00
|
|
|
|
|
|
|
|
index = dm->getEdgeDataArray(dm, CD_ORIGINDEX);
|
2013-08-01 18:33:35 +00:00
|
|
|
BM_ITER_MESH_INDEX (eed, &iter, bm, BM_EDGES_OF_MESH, i) {
|
2009-05-16 16:18:08 +00:00
|
|
|
MEdge *med = &medge[i];
|
|
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
BM_elem_index_set(eed, i); /* set_inline */
|
2009-06-23 05:35:49 +00:00
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
med->v1 = BM_elem_index_get(eed->v1);
|
|
|
|
|
med->v2 = BM_elem_index_get(eed->v2);
|
2011-03-27 03:29:27 +00:00
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
med->flag = BM_edge_flag_to_mflag(eed);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2012-05-22 07:26:45 +00:00
|
|
|
/* handle this differently to editmode switching,
|
|
|
|
|
* only enable draw for single user edges rather then calculating angle */
|
|
|
|
|
if ((med->flag & ME_EDGEDRAW) == 0) {
|
|
|
|
|
if (eed->l && eed->l == eed->l->radial_next) {
|
|
|
|
|
med->flag |= ME_EDGEDRAW;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2013-01-10 04:43:31 +00:00
|
|
|
if (cd_edge_crease_offset != -1) med->crease = BM_ELEM_CD_GET_FLOAT_AS_UCHAR(eed, cd_edge_crease_offset);
|
|
|
|
|
if (cd_edge_bweight_offset != -1) med->bweight = BM_ELEM_CD_GET_FLOAT_AS_UCHAR(eed, cd_edge_bweight_offset);
|
|
|
|
|
|
2009-06-23 05:35:49 +00:00
|
|
|
CustomData_from_bmesh_block(&bm->edata, &dm->edgeData, eed->head.data, i);
|
2013-08-01 18:33:35 +00:00
|
|
|
if (add_orig) *index++ = i;
|
2009-05-16 16:18:08 +00:00
|
|
|
}
|
2011-11-16 12:38:40 +00:00
|
|
|
bm->elem_index_dirty &= ~BM_EDGE;
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2012-01-18 15:09:27 +00:00
|
|
|
/* avoid this where possiblem, takes extra memory */
|
|
|
|
|
if (use_tessface) {
|
(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-02-12 10:51:45 +00:00
|
|
|
BM_mesh_elem_index_ensure(bm, BM_FACE);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2012-01-18 15:09:27 +00:00
|
|
|
index = dm->getTessFaceDataArray(dm, CD_ORIGINDEX);
|
2013-08-01 18:33:35 +00:00
|
|
|
for (i = 0; i < dm->numTessFaceData; i++) {
|
2012-01-18 15:09:27 +00:00
|
|
|
MFace *mf = &mface[i];
|
2012-10-24 07:24:11 +00:00
|
|
|
const BMLoop **l = em_looptris[i];
|
2012-01-18 15:09:27 +00:00
|
|
|
efa = l[0]->f;
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
mf->v1 = BM_elem_index_get(l[0]->v);
|
|
|
|
|
mf->v2 = BM_elem_index_get(l[1]->v);
|
|
|
|
|
mf->v3 = BM_elem_index_get(l[2]->v);
|
2012-01-18 15:09:27 +00:00
|
|
|
mf->v4 = 0;
|
|
|
|
|
mf->mat_nr = efa->mat_nr;
|
2012-02-12 10:51:45 +00:00
|
|
|
mf->flag = BM_face_flag_to_mflag(efa);
|
2012-01-18 15:09:27 +00:00
|
|
|
|
2012-10-30 19:20:17 +00:00
|
|
|
/* map mfaces to polygons in the same cddm intentionally */
|
2013-08-01 18:33:35 +00:00
|
|
|
*index++ = BM_elem_index_get(efa);
|
2012-01-18 15:09:27 +00:00
|
|
|
|
2017-05-25 15:11:00 +10:00
|
|
|
loops_to_customdata_corners(bm, &dm->faceData, i, l, numCol, numUV);
|
2012-01-18 15:09:27 +00:00
|
|
|
test_index_face(mf, &dm->faceData, i, 3);
|
|
|
|
|
}
|
2009-05-16 16:18:08 +00:00
|
|
|
}
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2009-06-23 05:35:49 +00:00
|
|
|
index = CustomData_get_layer(&dm->polyData, CD_ORIGINDEX);
|
(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
|
|
|
j = 0;
|
2013-08-01 18:33:35 +00:00
|
|
|
BM_ITER_MESH_INDEX (efa, &iter, bm, BM_FACES_OF_MESH, i) {
|
2012-12-21 07:28:14 +00:00
|
|
|
BMLoop *l_iter;
|
|
|
|
|
BMLoop *l_first;
|
(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
|
|
|
MPoly *mp = &mpoly[i];
|
|
|
|
|
|
2012-02-12 10:51:45 +00:00
|
|
|
BM_elem_index_set(efa, i); /* set_inline */
|
2012-01-18 15:09:27 +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
|
|
|
mp->totloop = efa->len;
|
2012-02-12 10:51:45 +00:00
|
|
|
mp->flag = BM_face_flag_to_mflag(efa);
|
(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
|
|
|
mp->loopstart = j;
|
|
|
|
|
mp->mat_nr = efa->mat_nr;
|
2012-12-21 07:28:14 +00:00
|
|
|
|
|
|
|
|
l_iter = l_first = BM_FACE_FIRST_LOOP(efa);
|
|
|
|
|
do {
|
|
|
|
|
mloop->v = BM_elem_index_get(l_iter->v);
|
|
|
|
|
mloop->e = BM_elem_index_get(l_iter->e);
|
|
|
|
|
CustomData_from_bmesh_block(&bm->ldata, &dm->loopData, l_iter->head.data, j);
|
(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-04-15 16:18:27 +02:00
|
|
|
BM_elem_index_set(l_iter, j); /* set_inline */
|
|
|
|
|
|
(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
|
|
|
j++;
|
|
|
|
|
mloop++;
|
2012-12-21 07:28:14 +00:00
|
|
|
} while ((l_iter = l_iter->next) != l_first);
|
(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
|
|
|
|
2009-06-23 05:35:49 +00:00
|
|
|
CustomData_from_bmesh_block(&bm->pdata, &dm->polyData, efa->head.data, i);
|
|
|
|
|
|
2013-08-01 18:33:35 +00:00
|
|
|
if (add_orig) *index++ = i;
|
(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-04-15 16:18:27 +02:00
|
|
|
bm->elem_index_dirty &= ~(BM_FACE | BM_LOOP);
|
2009-05-16 16:18:08 +00:00
|
|
|
|
2013-01-10 04:43:31 +00:00
|
|
|
dm->cd_flag = BM_mesh_cd_flag_from_bmesh(bm);
|
|
|
|
|
|
2009-05-16 16:18:08 +00:00
|
|
|
return dm;
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
{
|
2015-07-15 12:08:32 +10:00
|
|
|
return cddm_from_bmesh_ex(
|
|
|
|
|
bm, use_mdisps, false,
|
|
|
|
|
/* these vars are for editmesh only */
|
|
|
|
|
0, NULL);
|
2012-10-24 07:24:11 +00:00
|
|
|
}
|
|
|
|
|
|
2014-01-23 14:50:50 +01:00
|
|
|
DerivedMesh *CDDM_from_editbmesh(BMEditMesh *em, const bool use_mdisps, const bool use_tessface)
|
2012-10-24 07:24:11 +00:00
|
|
|
{
|
2015-07-15 12:08:32 +10:00
|
|
|
return cddm_from_bmesh_ex(
|
|
|
|
|
em->bm, use_mdisps,
|
|
|
|
|
/* editmesh */
|
|
|
|
|
use_tessface, em->tottri, (const BMLoop *(*)[3])em->looptris);
|
2012-10-24 07:24:11 +00:00
|
|
|
}
|
|
|
|
|
|
2018-10-15 18:11:37 +11:00
|
|
|
DerivedMesh *CDDM_copy(DerivedMesh *source)
|
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
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_copy cddm");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
int numVerts = source->numVertData;
|
|
|
|
|
int numEdges = source->numEdgeData;
|
2018-10-15 18:11:37 +11:00
|
|
|
int numTessFaces = 0;
|
(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
|
|
|
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
|
|
|
|
2017-02-02 14:32:05 +01:00
|
|
|
/* NOTE: Don't copy tessellation faces if not requested explicitly. */
|
|
|
|
|
|
2009-11-25 13:11:44 +00:00
|
|
|
/* ensure these are created if they are made on demand */
|
|
|
|
|
source->getVertDataArray(source, CD_ORIGINDEX);
|
|
|
|
|
source->getEdgeDataArray(source, CD_ORIGINDEX);
|
2012-10-30 19:20:17 +00:00
|
|
|
source->getPolyDataArray(source, CD_ORIGINDEX);
|
2009-11-25 13:11:44 +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
|
|
|
/* this initializes dm, and copies all non mvert/medge/mface layers */
|
2017-02-07 14:21:29 +01:00
|
|
|
DM_from_template(dm, source, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces,
|
2012-05-06 17:22:54 +00:00
|
|
|
numLoops, numPolys);
|
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
|
|
|
dm->deformedOnly = source->deformedOnly;
|
2013-01-10 04:43:31 +00:00
|
|
|
dm->cd_flag = source->cd_flag;
|
Fix [#30234] Various problems with CD layers and tesselation, related to modifiers stack.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
2012-03-18 22:06:57 +00:00
|
|
|
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
|
|
|
|
2017-02-16 09:55:44 +01:00
|
|
|
/* Tessellation data is never copied, so tag it here.
|
|
|
|
|
* Only tag dirty layers if we really ignored tessellation faces.
|
|
|
|
|
*/
|
2018-10-15 18:11:37 +11:00
|
|
|
dm->dirty |= DM_DIRTY_TESS_CDLAYERS;
|
2017-02-02 14:32:05 +01: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
|
|
|
CustomData_copy_data(&source->vertData, &dm->vertData, 0, 0, numVerts);
|
|
|
|
|
CustomData_copy_data(&source->edgeData, &dm->edgeData, 0, 0, numEdges);
|
|
|
|
|
|
|
|
|
|
/* now add mvert/medge/mface layers */
|
|
|
|
|
cddm->mvert = source->dupVertArray(source);
|
|
|
|
|
cddm->medge = source->dupEdgeArray(source);
|
|
|
|
|
|
2006-12-12 21:29:09 +00: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
|
|
|
|
2018-10-15 18:11:37 +11: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
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
return dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2010-10-20 09:18:55 +00:00
|
|
|
/* note, the CD_ORIGINDEX layers are all 0, so if there is a direct
|
2012-03-01 12:20:18 +00:00
|
|
|
* relationship between mesh data this needs to be set by the caller. */
|
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
|
|
|
DerivedMesh *CDDM_from_template_ex(DerivedMesh *source,
|
2015-07-15 12:08:32 +10:00
|
|
|
int numVerts, int numEdges, int numTessFaces,
|
2015-09-23 22:57:00 +10:00
|
|
|
int numLoops, int numPolys,
|
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 CustomData_MeshMasks *mask)
|
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
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_from_template dest");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
|
2010-07-27 12:01:40 +00:00
|
|
|
/* ensure these are created if they are made on demand */
|
|
|
|
|
source->getVertDataArray(source, CD_ORIGINDEX);
|
|
|
|
|
source->getEdgeDataArray(source, CD_ORIGINDEX);
|
2010-09-04 05:31:25 +00:00
|
|
|
source->getTessFaceDataArray(source, CD_ORIGINDEX);
|
2012-10-30 19:20:17 +00:00
|
|
|
source->getPolyDataArray(source, CD_ORIGINDEX);
|
2010-07-27 12:01:40 +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
|
|
|
/* this does a copy of all non mvert/medge/mface layers */
|
2015-09-23 22:57:00 +10:00
|
|
|
DM_from_template_ex(
|
|
|
|
|
dm, source, DM_TYPE_CDDM,
|
|
|
|
|
numVerts, numEdges, numTessFaces,
|
|
|
|
|
numLoops, numPolys,
|
|
|
|
|
mask);
|
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
|
|
|
|
|
|
|
|
/* now add mvert/medge/mface layers */
|
2006-12-12 21:29:09 +00:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_CALLOC, NULL, numVerts);
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
|
2011-11-30 18:03:56 +00:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_CALLOC, NULL, numTessFaces);
|
(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_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
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!CustomData_get_layer(&dm->vertData, CD_ORIGINDEX))
|
2009-11-04 20:23:48 +00:00
|
|
|
CustomData_add_layer(&dm->vertData, CD_ORIGINDEX, CD_CALLOC, NULL, numVerts);
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!CustomData_get_layer(&dm->edgeData, CD_ORIGINDEX))
|
2009-11-04 20:23:48 +00:00
|
|
|
CustomData_add_layer(&dm->edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
|
2012-03-24 06:18:31 +00:00
|
|
|
if (!CustomData_get_layer(&dm->faceData, CD_ORIGINDEX))
|
2011-11-30 18:03:56 +00:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
|
2009-11-04 20:23:48 +00:00
|
|
|
|
2006-12-12 21:29:09 +00: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);
|
(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
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
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
|
|
|
|
|
|
|
|
return dm;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
2015-09-23 22:57:00 +10:00
|
|
|
DerivedMesh *CDDM_from_template(
|
|
|
|
|
DerivedMesh *source,
|
|
|
|
|
int numVerts, int numEdges, int numTessFaces,
|
|
|
|
|
int numLoops, int numPolys)
|
|
|
|
|
{
|
|
|
|
|
return CDDM_from_template_ex(
|
|
|
|
|
source, numVerts, numEdges, numTessFaces,
|
|
|
|
|
numLoops, numPolys,
|
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
|
|
|
&CD_MASK_DERIVEDMESH);
|
2015-09-23 22:57:00 +10:00
|
|
|
}
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
|
void CDDM_apply_vert_coords(DerivedMesh *dm, float (*vertCoords)[3])
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
MVert *vert;
|
2006-08-28 01:12:36 +00:00
|
|
|
int i;
|
|
|
|
|
|
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
|
|
|
/* this will just return the pointer if it wasn't a referenced layer */
|
2011-12-19 08:26:53 +00:00
|
|
|
vert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
|
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
|
|
|
cddm->mvert = vert;
|
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (i = 0; i < dm->numVertData; ++i, ++vert)
|
2011-11-07 01:38:32 +00:00
|
|
|
copy_v3_v3(vert->co, vertCoords[i]);
|
2013-05-30 17:36:43 +00:00
|
|
|
|
|
|
|
|
cddm->dm.dirty |= DM_DIRTY_NORMALS;
|
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_apply_vert_normals(DerivedMesh *dm, short (*vertNormals)[3])
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
MVert *vert;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* this will just return the pointer if it wasn't a referenced layer */
|
2011-12-19 08:26:53 +00:00
|
|
|
vert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
|
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
|
|
|
cddm->mvert = vert;
|
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
for (i = 0; i < dm->numVertData; ++i, ++vert)
|
2011-09-12 04:14:12 +00:00
|
|
|
copy_v3_v3_short(vert->no, vertNormals[i]);
|
2013-05-30 17:36:43 +00:00
|
|
|
|
|
|
|
|
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
|
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
|
|
|
}
|
|
|
|
|
|
2014-01-23 14:50:50 +01:00
|
|
|
void CDDM_calc_normals_mapping_ex(DerivedMesh *dm, const bool only_face_normals)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2011-04-15 01:19:13 +00:00
|
|
|
float (*face_nors)[3] = NULL;
|
2011-12-07 01:12:53 +00:00
|
|
|
|
2013-06-25 14:31:52 +00:00
|
|
|
if (dm->numVertData == 0) {
|
|
|
|
|
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
|
|
|
|
|
return;
|
|
|
|
|
}
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2011-12-07 01:12:53 +00:00
|
|
|
/* now we skip calculating vertex normals for referenced layer,
|
|
|
|
|
* no need to duplicate verts.
|
|
|
|
|
* WATCH THIS, bmesh only change!,
|
|
|
|
|
* need to take care of the side effects here - campbell */
|
2013-12-22 14:11:10 +11:00
|
|
|
#if 0
|
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
|
|
|
/* we don't want to overwrite any referenced layers */
|
2011-12-19 08:26:53 +00:00
|
|
|
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
|
2013-12-22 14:11:10 +11:00
|
|
|
#endif
|
2011-11-13 15:13:59 +00:00
|
|
|
|
2015-07-17 20:14:17 +10:00
|
|
|
#if 0
|
2011-11-30 18:03:56 +00:00
|
|
|
if (dm->numTessFaceData == 0) {
|
2012-03-02 16:05:54 +00:00
|
|
|
/* No tessellation on this mesh yet, need to calculate one.
|
2012-01-19 19:23:25 +00:00
|
|
|
*
|
|
|
|
|
* Important not to update face normals from polys since it
|
2012-07-18 11:01:23 +00:00
|
|
|
* interferes with assigning the new normal layer in the following code.
|
2012-01-19 19:23:25 +00:00
|
|
|
*/
|
2014-01-23 14:50:50 +01:00
|
|
|
CDDM_recalc_tessellation_ex(dm, false);
|
2011-11-13 15:13:59 +00:00
|
|
|
}
|
|
|
|
|
else {
|
2012-10-30 19:20:17 +00:00
|
|
|
/* A tessellation already exists, it should always have a CD_ORIGINDEX */
|
|
|
|
|
BLI_assert(CustomData_has_layer(&dm->faceData, CD_ORIGINDEX));
|
2011-11-30 18:03:56 +00:00
|
|
|
CustomData_free_layers(&dm->faceData, CD_NORMAL, dm->numTessFaceData);
|
2011-11-13 15:13:59 +00:00
|
|
|
}
|
2015-07-17 20:14:17 +10:00
|
|
|
#endif
|
2011-11-13 15:13:59 +00:00
|
|
|
|
2018-01-14 22:14:20 +01:00
|
|
|
face_nors = MEM_malloc_arrayN(dm->numPolyData, sizeof(*face_nors), "face_nors");
|
2012-03-18 06:49:32 +00:00
|
|
|
|
2011-04-15 01:19:13 +00:00
|
|
|
/* calculate face normals */
|
2015-07-17 03:36:03 +10:00
|
|
|
BKE_mesh_calc_normals_poly(
|
2015-10-12 20:12:55 +02:00
|
|
|
cddm->mvert, NULL, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
|
2015-07-17 03:36:03 +10:00
|
|
|
dm->numLoopData, dm->numPolyData, face_nors,
|
2015-07-15 12:08:32 +10:00
|
|
|
only_face_normals);
|
2012-03-18 06:49:32 +00:00
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
CustomData_add_layer(&dm->polyData, CD_NORMAL, CD_ASSIGN, face_nors, dm->numPolyData);
|
2013-05-30 17:36:43 +00:00
|
|
|
|
|
|
|
|
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
|
2012-03-18 06:49:32 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_calc_normals_mapping(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
/* use this to skip calculating normals on original vert's, this may need to be changed */
|
2014-01-23 14:50:50 +01:00
|
|
|
const bool only_face_normals = CustomData_is_referenced_layer(&dm->vertData, CD_MVERT);
|
2012-01-19 17:51:52 +00:00
|
|
|
|
2012-03-18 06:49:32 +00:00
|
|
|
CDDM_calc_normals_mapping_ex(dm, only_face_normals);
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2013-05-30 18:09:19 +00:00
|
|
|
#if 0
|
2012-01-06 00:45:07 +00:00
|
|
|
/* bmesh note: this matches what we have in trunk */
|
|
|
|
|
void CDDM_calc_normals(DerivedMesh *dm)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2012-01-06 00:45:07 +00:00
|
|
|
float (*poly_nors)[3];
|
|
|
|
|
|
2012-03-24 06:18:31 +00:00
|
|
|
if (dm->numVertData == 0) return;
|
2012-01-06 00:45:07 +00:00
|
|
|
|
|
|
|
|
/* we don't want to overwrite any referenced layers */
|
|
|
|
|
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
|
|
|
|
|
|
|
|
|
|
/* fill in if it exists */
|
|
|
|
|
poly_nors = CustomData_get_layer(&dm->polyData, CD_NORMAL);
|
|
|
|
|
if (!poly_nors) {
|
|
|
|
|
poly_nors = CustomData_add_layer(&dm->polyData, CD_NORMAL, CD_CALLOC, NULL, dm->numPolyData);
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-28 14:23:07 +00:00
|
|
|
BKE_mesh_calc_normals_poly(cddm->mvert, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
|
2013-06-12 09:35:02 +00:00
|
|
|
dm->numLoopData, dm->numPolyData, poly_nors, false);
|
2013-05-30 17:36:43 +00:00
|
|
|
|
|
|
|
|
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
|
2012-01-06 00:45:07 +00:00
|
|
|
}
|
2013-05-30 18:09:19 +00:00
|
|
|
#else
|
|
|
|
|
|
|
|
|
|
/* poly normal layer is now only for final display */
|
|
|
|
|
void CDDM_calc_normals(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
|
|
|
|
|
/* we don't want to overwrite any referenced layers */
|
|
|
|
|
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
|
|
|
|
|
|
2015-10-12 20:12:55 +02:00
|
|
|
BKE_mesh_calc_normals_poly(cddm->mvert, NULL, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
|
2013-06-12 09:35:02 +00:00
|
|
|
dm->numLoopData, dm->numPolyData, NULL, false);
|
2013-05-30 18:09:19 +00:00
|
|
|
|
|
|
|
|
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|
2012-01-06 00:45:07 +00:00
|
|
|
|
2015-01-19 14:11:40 +01:00
|
|
|
void CDDM_calc_loop_normals(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
|
|
|
{
|
|
|
|
|
CDDM_calc_loop_normals_spacearr(dm, use_split_normals, split_angle, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* #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
|
|
|
|
|
|
|
|
void CDDM_calc_loop_normals_spacearr(
|
|
|
|
|
DerivedMesh *dm, const bool use_split_normals, const float split_angle, MLoopNorSpaceArray *r_lnors_spacearr)
|
2014-04-13 12:18:51 +02:00
|
|
|
{
|
|
|
|
|
MVert *mverts = dm->getVertArray(dm);
|
|
|
|
|
MEdge *medges = dm->getEdgeArray(dm);
|
|
|
|
|
MLoop *mloops = dm->getLoopArray(dm);
|
|
|
|
|
MPoly *mpolys = dm->getPolyArray(dm);
|
|
|
|
|
|
|
|
|
|
CustomData *ldata, *pdata;
|
|
|
|
|
|
|
|
|
|
float (*lnors)[3];
|
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
|
|
|
short (*clnor_data)[2];
|
2014-04-13 12:18:51 +02:00
|
|
|
float (*pnors)[3];
|
|
|
|
|
|
|
|
|
|
const int numVerts = dm->getNumVerts(dm);
|
|
|
|
|
const int numEdges = dm->getNumEdges(dm);
|
|
|
|
|
const int numLoops = dm->getNumLoops(dm);
|
|
|
|
|
const int numPolys = dm->getNumPolys(dm);
|
|
|
|
|
|
|
|
|
|
ldata = dm->getLoopDataLayout(dm);
|
|
|
|
|
if (CustomData_has_layer(ldata, CD_NORMAL)) {
|
|
|
|
|
lnors = CustomData_get_layer(ldata, CD_NORMAL);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
lnors = CustomData_add_layer(ldata, CD_NORMAL, CD_CALLOC, NULL, numLoops);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Compute poly (always needed) and vert normals. */
|
|
|
|
|
/* Note we can't use DM_ensure_normals, since it won't keep computed poly nors... */
|
|
|
|
|
pdata = dm->getPolyDataLayout(dm);
|
|
|
|
|
pnors = CustomData_get_layer(pdata, CD_NORMAL);
|
|
|
|
|
if (!pnors) {
|
|
|
|
|
pnors = CustomData_add_layer(pdata, CD_NORMAL, CD_CALLOC, NULL, numPolys);
|
|
|
|
|
}
|
2015-10-12 20:12:55 +02:00
|
|
|
BKE_mesh_calc_normals_poly(mverts, NULL, numVerts, mloops, mpolys, numLoops, numPolys, pnors,
|
2014-04-13 12:18:51 +02:00
|
|
|
(dm->dirty & DM_DIRTY_NORMALS) ? false : true);
|
|
|
|
|
|
|
|
|
|
dm->dirty &= ~DM_DIRTY_NORMALS;
|
|
|
|
|
|
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
|
|
|
clnor_data = CustomData_get_layer(ldata, CD_CUSTOMLOOPNORMAL);
|
|
|
|
|
|
2014-04-13 12:18:51 +02:00
|
|
|
BKE_mesh_normals_loop_split(mverts, numVerts, medges, numEdges, mloops, lnors, numLoops,
|
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
|
|
|
mpolys, (const float (*)[3])pnors, numPolys,
|
|
|
|
|
use_split_normals, split_angle,
|
|
|
|
|
r_lnors_spacearr, clnor_data, NULL);
|
|
|
|
|
#ifdef DEBUG_CLNORS
|
|
|
|
|
if (r_lnors_spacearr) {
|
|
|
|
|
int i;
|
|
|
|
|
for (i = 0; i < numLoops; i++) {
|
|
|
|
|
if (r_lnors_spacearr->lspacearr[i]->ref_alpha != 0.0f) {
|
|
|
|
|
LinkNode *loops = r_lnors_spacearr->lspacearr[i]->loops;
|
|
|
|
|
printf("Loop %d uses lnor space %p:\n", i, r_lnors_spacearr->lspacearr[i]);
|
|
|
|
|
print_v3("\tfinal lnor", lnors[i]);
|
|
|
|
|
print_v3("\tauto lnor", r_lnors_spacearr->lspacearr[i]->vec_lnor);
|
|
|
|
|
print_v3("\tref_vec", r_lnors_spacearr->lspacearr[i]->vec_ref);
|
|
|
|
|
printf("\talpha: %f\n\tbeta: %f\n\tloops: %p\n", r_lnors_spacearr->lspacearr[i]->ref_alpha,
|
|
|
|
|
r_lnors_spacearr->lspacearr[i]->ref_beta, r_lnors_spacearr->lspacearr[i]->loops);
|
|
|
|
|
printf("\t\t(shared with loops");
|
|
|
|
|
while (loops) {
|
2018-09-19 12:05:58 +10:00
|
|
|
printf(" %d", POINTER_AS_INT(loops->link));
|
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
|
|
|
loops = loops->next;
|
|
|
|
|
}
|
|
|
|
|
printf(")\n");
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
printf("Loop %d has no lnor space\n", i);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2014-04-13 12:18:51 +02: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(DerivedMesh *dm, int numVerts)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2013-11-04 12:01:46 +00:00
|
|
|
BLI_assert(numVerts >= 0);
|
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 (numVerts < dm->numVertData)
|
2012-05-06 17:22:54 +00:00
|
|
|
CustomData_free_elem(&dm->vertData, numVerts, dm->numVertData - numVerts);
|
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
|
|
|
|
|
|
|
|
dm->numVertData = numVerts;
|
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_edges(DerivedMesh *dm, int numEdges)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2013-11-04 12:01:46 +00:00
|
|
|
BLI_assert(numEdges >= 0);
|
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 (numEdges < dm->numEdgeData)
|
2012-05-06 17:22:54 +00:00
|
|
|
CustomData_free_elem(&dm->edgeData, numEdges, dm->numEdgeData - 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
|
|
|
|
|
|
|
|
dm->numEdgeData = numEdges;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
2011-12-31 12:58:03 +00:00
|
|
|
void CDDM_lower_num_tessfaces(DerivedMesh *dm, int numTessFaces)
|
|
|
|
|
{
|
2013-11-04 12:01:46 +00:00
|
|
|
BLI_assert(numTessFaces >= 0);
|
2011-12-31 12:58:03 +00:00
|
|
|
if (numTessFaces < dm->numTessFaceData)
|
2012-05-06 17:22:54 +00:00
|
|
|
CustomData_free_elem(&dm->faceData, numTessFaces, dm->numTessFaceData - numTessFaces);
|
2011-12-31 12:58:03 +00:00
|
|
|
|
|
|
|
|
dm->numTessFaceData = numTessFaces;
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-04 12:01:46 +00:00
|
|
|
void CDDM_lower_num_loops(DerivedMesh *dm, int numLoops)
|
|
|
|
|
{
|
|
|
|
|
BLI_assert(numLoops >= 0);
|
|
|
|
|
if (numLoops < dm->numLoopData)
|
|
|
|
|
CustomData_free_elem(&dm->loopData, numLoops, dm->numLoopData - numLoops);
|
|
|
|
|
|
|
|
|
|
dm->numLoopData = numLoops;
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-30 18:03:56 +00:00
|
|
|
void CDDM_lower_num_polys(DerivedMesh *dm, int numPolys)
|
2006-08-28 01:12:36 +00:00
|
|
|
{
|
2013-11-04 12:01:46 +00:00
|
|
|
BLI_assert(numPolys >= 0);
|
2011-11-30 18:03:56 +00:00
|
|
|
if (numPolys < dm->numPolyData)
|
2012-05-06 17:22:54 +00:00
|
|
|
CustomData_free_elem(&dm->polyData, numPolys, dm->numPolyData - numPolys);
|
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
|
|
|
|
2011-11-30 18:03:56 +00:00
|
|
|
dm->numPolyData = numPolys;
|
2006-08-28 01:12:36 +00: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)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
return &((CDDerivedMesh *)dm)->mvert[index];
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEdge *CDDM_get_edge(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
{
|
2012-05-06 17:22:54 +00: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)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
return &((CDDerivedMesh *)dm)->mloop[index];
|
2012-02-07 01:13:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MPoly *CDDM_get_poly(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
return ((CDDerivedMesh *)dm)->mvert;
|
2006-08-28 01:12:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEdge *CDDM_get_edges(DerivedMesh *dm)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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
|
|
|
{
|
2012-05-06 17:22:54 +00: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)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00: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)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
return ((CDDerivedMesh *)dm)->mpoly;
|
2011-02-27 06:19:40 +00:00
|
|
|
}
|
|
|
|
|
|
2009-09-11 10:21:54 +00:00
|
|
|
void CDDM_set_mvert(DerivedMesh *dm, MVert *mvert)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2018-06-17 17:05:51 +02:00
|
|
|
|
2011-04-22 23:37:58 +00:00
|
|
|
if (!CustomData_has_layer(&dm->vertData, CD_MVERT))
|
|
|
|
|
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_ASSIGN, mvert, dm->numVertData);
|
2015-07-15 12:08:32 +10:00
|
|
|
|
2009-09-11 10:21:54 +00:00
|
|
|
cddm->mvert = mvert;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_set_medge(DerivedMesh *dm, MEdge *medge)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2010-01-05 22:33:41 +00:00
|
|
|
|
2011-04-22 23:37:58 +00:00
|
|
|
if (!CustomData_has_layer(&dm->edgeData, CD_MEDGE))
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_ASSIGN, medge, dm->numEdgeData);
|
|
|
|
|
|
2009-09-11 10:21:54 +00:00
|
|
|
cddm->medge = medge;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_set_mface(DerivedMesh *dm, MFace *mface)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2009-01-06 18:59:03 +00:00
|
|
|
|
2011-04-22 23:37:58 +00:00
|
|
|
if (!CustomData_has_layer(&dm->faceData, CD_MFACE))
|
2011-11-30 18:03:56 +00:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_ASSIGN, mface, dm->numTessFaceData);
|
2011-04-22 23:37:58 +00:00
|
|
|
|
2010-01-05 22:33:41 +00:00
|
|
|
cddm->mface = mface;
|
2009-01-06 18:59:03 +00:00
|
|
|
}
|
2012-02-29 15:00:37 +00:00
|
|
|
|
|
|
|
|
void CDDM_set_mloop(DerivedMesh *dm, MLoop *mloop)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2012-02-29 15:00:37 +00:00
|
|
|
|
|
|
|
|
if (!CustomData_has_layer(&dm->loopData, CD_MLOOP))
|
|
|
|
|
CustomData_add_layer(&dm->loopData, CD_MLOOP, CD_ASSIGN, mloop, dm->numLoopData);
|
|
|
|
|
|
|
|
|
|
cddm->mloop = mloop;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_set_mpoly(DerivedMesh *dm, MPoly *mpoly)
|
|
|
|
|
{
|
2012-05-06 17:22:54 +00:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2012-02-29 15:00:37 +00:00
|
|
|
|
|
|
|
|
if (!CustomData_has_layer(&dm->polyData, CD_MPOLY))
|
|
|
|
|
CustomData_add_layer(&dm->polyData, CD_MPOLY, CD_ASSIGN, mpoly, dm->numPolyData);
|
|
|
|
|
|
|
|
|
|
cddm->mpoly = mpoly;
|
|
|
|
|
}
|
