2010-01-05 23:33:41 +01:00
|
|
|
/*
|
2011-10-10 11:38:02 +02:00
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
|
*
|
|
|
|
|
* 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.
|
|
|
|
|
*
|
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
|
*
|
|
|
|
|
* Contributor(s): Ben Batt <benbatt@gmail.com>
|
|
|
|
|
*
|
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
|
*
|
|
|
|
|
* Implementation of CDDerivedMesh.
|
|
|
|
|
*
|
|
|
|
|
* BKE_cdderivedmesh.h contains the function prototypes for this file.
|
|
|
|
|
*
|
|
|
|
|
*/
|
2011-02-27 21:40:57 +01:00
|
|
|
|
|
|
|
|
/** \file blender/blenkernel/intern/cdderivedmesh.c
|
|
|
|
|
* \ingroup bke
|
|
|
|
|
*/
|
2011-10-10 11:38:02 +02:00
|
|
|
|
2011-09-14 02:37:27 +02:00
|
|
|
#include "GL/glew.h"
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-08-28 11:36:31 +02:00
|
|
|
#include "BLI_scanfill.h"
|
2009-11-10 21:43:45 +01:00
|
|
|
#include "BLI_math.h"
|
2006-08-28 03:12:36 +02:00
|
|
|
#include "BLI_blenlib.h"
|
|
|
|
|
#include "BLI_edgehash.h"
|
2010-03-22 12:59:36 +01:00
|
|
|
#include "BLI_math.h"
|
2009-10-27 20:53:34 +01:00
|
|
|
#include "BLI_pbvh.h"
|
2011-02-15 02:16:32 +01:00
|
|
|
#include "BLI_array.h"
|
|
|
|
|
#include "BLI_smallhash.h"
|
2011-01-07 19:36:47 +01:00
|
|
|
#include "BLI_utildefines.h"
|
|
|
|
|
|
|
|
|
|
#include "BKE_cdderivedmesh.h"
|
|
|
|
|
#include "BKE_global.h"
|
|
|
|
|
#include "BKE_mesh.h"
|
|
|
|
|
#include "BKE_paint.h"
|
2012-03-24 02:24:58 +01:00
|
|
|
#include "BKE_utildefines.h"
|
|
|
|
|
#include "BKE_tessmesh.h"
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2012-02-19 23:17:30 +01:00
|
|
|
#include "DNA_mesh_types.h"
|
2006-08-28 03:12:36 +02: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 05:28:02 +01:00
|
|
|
#include "DNA_object_types.h"
|
2010-03-08 14:49:13 +01:00
|
|
|
#include "DNA_curve_types.h" /* for Curve */
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
#include "MEM_guardedalloc.h"
|
|
|
|
|
|
2010-07-14 12:46:12 +02:00
|
|
|
#include "GPU_buffers.h"
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
#include "GPU_draw.h"
|
|
|
|
|
#include "GPU_extensions.h"
|
|
|
|
|
#include "GPU_material.h"
|
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
#include <string.h>
|
|
|
|
|
#include <limits.h>
|
2009-01-06 19:59:03 +01:00
|
|
|
#include <math.h>
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
typedef struct {
|
|
|
|
|
DerivedMesh dm;
|
|
|
|
|
|
|
|
|
|
/* these point to data in the DerivedMesh custom data layers,
|
2012-03-09 19:28:30 +01: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 05:28:02 +01: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 12:06:25 +02:00
|
|
|
MLoop *mloop;
|
|
|
|
|
MPoly *mpoly;
|
2009-10-28 07:06:05 +01:00
|
|
|
|
|
|
|
|
/* Cached */
|
|
|
|
|
struct PBVH *pbvh;
|
2010-06-02 20:04:31 +02:00
|
|
|
int pbvh_draw;
|
2011-01-31 21:02:51 +01:00
|
|
|
|
2009-10-28 07:06:05 +01:00
|
|
|
/* Mesh connectivity */
|
2012-03-17 05:41:36 +01: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 05:28:02 +01:00
|
|
|
} CDDerivedMesh;
|
2006-08-28 03:12:36 +02: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 05:28:02 +01:00
|
|
|
return dm->numVertData;
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
static int cdDM_getNumEdges(DerivedMesh *dm)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
return dm->numEdgeData;
|
2006-08-28 03:12:36 +02: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 12:06:25 +02:00
|
|
|
static int cdDM_getNumTessFaces(DerivedMesh *dm)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2012-02-27 10:37:59 +01: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) {
|
|
|
|
|
printf("%s: has no faces!, call DM_ensure_tessface() if you need them\n");
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2011-11-30 19:03:56 +01:00
|
|
|
return dm->numTessFaceData;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int cdDM_getNumLoops(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
return dm->numLoopData;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-11-29 14:01:51 +01: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 12:06:25 +02:00
|
|
|
{
|
|
|
|
|
return dm->numPolyData;
|
|
|
|
|
}
|
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
static void cdDM_getVert(DerivedMesh *dm, int index, MVert *vert_r)
|
|
|
|
|
{
|
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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
*vert_r = cddm->mvert[index];
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_getEdge(DerivedMesh *dm, int index, MEdge *edge_r)
|
|
|
|
|
{
|
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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
*edge_r = cddm->medge[index];
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-11-29 14:01:51 +01:00
|
|
|
static void cdDM_getTessFace(DerivedMesh *dm, int index, MFace *face_r)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
*face_r = cddm->mface[index];
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
static void cdDM_copyVertArray(DerivedMesh *dm, MVert *vert_r)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(vert_r, cddm->mvert, sizeof(*vert_r) * dm->numVertData);
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
static void cdDM_copyEdgeArray(DerivedMesh *dm, MEdge *edge_r)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(edge_r, cddm->medge, sizeof(*edge_r) * dm->numEdgeData);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-11-29 14:01:51 +01:00
|
|
|
static void cdDM_copyTessFaceArray(DerivedMesh *dm, MFace *face_r)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
2011-11-30 19:03:56 +01:00
|
|
|
memcpy(face_r, cddm->mface, sizeof(*face_r) * dm->numTessFaceData);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-06-14 05:16:08 +02:00
|
|
|
static void cdDM_copyLoopArray(DerivedMesh *dm, MLoop *loop_r)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(loop_r, cddm->mloop, sizeof(*loop_r) * dm->numLoopData);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_copyPolyArray(DerivedMesh *dm, MPoly *poly_r)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
|
|
|
|
|
memcpy(poly_r, cddm->mpoly, sizeof(*poly_r) * dm->numPolyData);
|
|
|
|
|
}
|
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
static void cdDM_getMinMax(DerivedMesh *dm, float min_r[3], float max_r[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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
2006-08-28 03:12:36 +02: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 05:28:02 +01:00
|
|
|
if (dm->numVertData) {
|
|
|
|
|
for (i=0; i<dm->numVertData; i++) {
|
|
|
|
|
DO_MINMAX(cddm->mvert[i].co, min_r, max_r);
|
|
|
|
|
}
|
2012-03-23 21:18:09 +01:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
zero_v3(min_r);
|
|
|
|
|
zero_v3(max_r);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_getVertCo(DerivedMesh *dm, int index, float co_r[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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v3_v3(co_r, cddm->mvert[index].co);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_getVertCos(DerivedMesh *dm, float (*cos_r)[3])
|
|
|
|
|
{
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
int i;
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
for(i = 0; i < dm->numVertData; i++, mv++)
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v3_v3(cos_r[i], mv->co);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_getVertNo(DerivedMesh *dm, int index, float no_r[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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
2011-04-27 06:57:57 +02:00
|
|
|
normal_short_to_float_v3(no_r, cddm->mvert[index].no);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2012-03-17 11:23:44 +01:00
|
|
|
static const MeshElemMap *cdDM_getPolyMap(Object *ob, DerivedMesh *dm)
|
2012-02-05 07:20:51 +01:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
|
|
|
|
|
if(!cddm->pmap && ob->type == OB_MESH) {
|
|
|
|
|
Mesh *me= ob->data;
|
|
|
|
|
|
|
|
|
|
create_vert_poly_map(&cddm->pmap, &cddm->pmap_mem,
|
|
|
|
|
me->mpoly, me->mloop,
|
2012-02-05 08:09:30 +01:00
|
|
|
me->totvert, me->totpoly, me->totloop);
|
2012-02-05 07:20:51 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return cddm->pmap;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-21 22:10:59 +02:00
|
|
|
static int can_pbvh_draw(Object *ob, DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
2011-01-08 11:23:36 +01:00
|
|
|
Mesh *me= ob->data;
|
2011-04-23 11:07:46 +02:00
|
|
|
int deformed= 0;
|
2010-06-21 22:10:59 +02:00
|
|
|
|
2011-04-23 11:07:46 +02:00
|
|
|
/* active modifiers means extra deformation, which can't be handled correct
|
2012-03-09 19:28:30 +01:00
|
|
|
* on bith of PBVH and sculpt "layer" levels, so use PBVH only for internal brush
|
|
|
|
|
* stuff and show final DerivedMesh so user would see actual object shape */
|
2011-04-23 11:07:46 +02:00
|
|
|
deformed|= ob->sculpt->modifiers_active;
|
|
|
|
|
|
|
|
|
|
/* as in case with modifiers, we can't synchronize deformation made against
|
2012-03-09 19:28:30 +01:00
|
|
|
* PBVH and non-locked keyblock, so also use PBVH only for brushes and
|
|
|
|
|
* final DM to give final result to user */
|
2011-04-23 11:07:46 +02:00
|
|
|
deformed|= ob->sculpt->kb && (ob->shapeflag&OB_SHAPE_LOCK) == 0;
|
2010-06-21 22:10:59 +02:00
|
|
|
|
2011-04-23 11:07:46 +02:00
|
|
|
if(deformed)
|
|
|
|
|
return 0;
|
2010-06-21 22:10:59 +02:00
|
|
|
|
2011-09-07 14:47:23 +02:00
|
|
|
return cddm->mvert == me->mvert || ob->sculpt->kb;
|
2010-06-21 22:10:59 +02:00
|
|
|
}
|
|
|
|
|
|
2009-11-25 14:11:44 +01:00
|
|
|
static struct PBVH *cdDM_getPBVH(Object *ob, DerivedMesh *dm)
|
2009-10-28 07:06:05 +01:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
|
2010-03-22 12:59:36 +01:00
|
|
|
if(!ob) {
|
|
|
|
|
cddm->pbvh= NULL;
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(!ob->sculpt)
|
|
|
|
|
return NULL;
|
2010-06-02 20:04:31 +02:00
|
|
|
if(ob->sculpt->pbvh) {
|
2010-03-22 12:59:36 +01:00
|
|
|
cddm->pbvh= ob->sculpt->pbvh;
|
2010-06-21 22:10:59 +02:00
|
|
|
cddm->pbvh_draw = can_pbvh_draw(ob, dm);
|
2010-06-02 20:04:31 +02:00
|
|
|
}
|
2009-11-25 14:11:44 +01:00
|
|
|
|
2010-06-02 20:04:31 +02:00
|
|
|
/* always build pbvh from original mesh, and only use it for drawing if
|
2012-03-09 19:28:30 +01: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 */
|
2009-11-25 14:11:44 +01:00
|
|
|
if(!cddm->pbvh && ob->type == OB_MESH) {
|
2011-05-04 15:15:42 +02:00
|
|
|
SculptSession *ss= ob->sculpt;
|
2010-12-17 20:05:10 +01:00
|
|
|
Mesh *me= ob->data;
|
Sculpt: Multithreading & PBVH Changes
* Sculpting, normal update and bounding box code is now multithreaded
using OpenMP.
* Fix a number of update issues: normals on node boundaries, outdated
bounding boxes, partial redraw, .. . There's probably still a few
left, but should be better now.
* Clicking once now does a single paint instead of two (was also
painting on mouse up event).
* Smooth shading now is enabled for the full mesh when the first face
uses it (so it can be tested at least).
Implementation Notes:
* PBVH search can now be done either using a callback or bt gathering the
nodes in an array. The latter makes multithreading with OpenMP easier.
* Normals update code is now inside PBVH, was doing it per node before but
should do all faces first and only then vertices.
* Instead of using search modes + 1 modified flag, now nodes get 4 flags
to indicate what needs to be updated for them, found that this makes it
easier for me to understand the code and fix update bugs.
* PBVHNode is now exposed as an abstract type, I think this makes it more
clear what is happening than having it's data passed as part of callback
functions.
* Active_verts list was replaced by looping over nodes and the vertices
inside them. However the grab brush still uses the active_verts system,
will fix that later.
* Some micro-optimizations, like avoiding a few multiplications/divisions,
using local variables instead of pointers, or looping over fewer vertices
to update the bounding boxes.
2009-11-02 19:47:03 +01:00
|
|
|
cddm->pbvh = BLI_pbvh_new();
|
2010-06-21 22:10:59 +02:00
|
|
|
cddm->pbvh_draw = can_pbvh_draw(ob, dm);
|
2012-03-14 07:30:55 +01:00
|
|
|
|
|
|
|
|
BKE_mesh_tessface_ensure(me);
|
|
|
|
|
|
2009-11-25 14:40:43 +01:00
|
|
|
BLI_pbvh_build_mesh(cddm->pbvh, me->mface, me->mvert,
|
2011-11-11 14:09:14 +01:00
|
|
|
me->totface, me->totvert);
|
2011-01-31 21:02:51 +01:00
|
|
|
|
2011-05-04 15:15:42 +02:00
|
|
|
if(ss->modifiers_active && ob->derivedDeform) {
|
|
|
|
|
DerivedMesh *deformdm= ob->derivedDeform;
|
2011-01-31 21:02:51 +01:00
|
|
|
float (*vertCos)[3];
|
|
|
|
|
int totvert;
|
|
|
|
|
|
2011-05-04 15:15:42 +02:00
|
|
|
totvert= deformdm->getNumVerts(deformdm);
|
2011-01-31 21:02:51 +01:00
|
|
|
vertCos= MEM_callocN(3*totvert*sizeof(float), "cdDM_getPBVH vertCos");
|
2011-05-04 15:15:42 +02:00
|
|
|
deformdm->getVertCos(deformdm, vertCos);
|
2011-01-31 21:02:51 +01:00
|
|
|
BLI_pbvh_apply_vertCos(cddm->pbvh, vertCos);
|
|
|
|
|
MEM_freeN(vertCos);
|
|
|
|
|
}
|
2009-10-28 07:06:05 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return cddm->pbvh;
|
|
|
|
|
}
|
|
|
|
|
|
2010-12-14 04:30:30 +01:00
|
|
|
/* update vertex normals so that drawing smooth faces works during sculpt
|
2012-03-09 19:28:30 +01:00
|
|
|
* TODO: proper fix is to support the pbvh in all drawing modes */
|
2010-12-14 04:30:30 +01:00
|
|
|
static void cdDM_update_normals_from_pbvh(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
float (*face_nors)[3];
|
|
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
if(!cddm->pbvh || !cddm->pbvh_draw || !dm->numTessFaceData)
|
2010-12-14 04:30:30 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
face_nors = CustomData_get_layer(&dm->faceData, CD_NORMAL);
|
|
|
|
|
|
|
|
|
|
BLI_pbvh_update(cddm->pbvh, PBVH_UpdateNormals, face_nors);
|
|
|
|
|
}
|
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
static void cdDM_drawVerts(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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mv = cddm->mvert;
|
2006-08-28 03:12:36 +02:00
|
|
|
int i;
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if( GPU_buffer_legacy(dm) ) {
|
|
|
|
|
glBegin(GL_POINTS);
|
|
|
|
|
for(i = 0; i < dm->numVertData; i++, mv++)
|
|
|
|
|
glVertex3fv(mv->co);
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
else { /* use OpenGL VBOs or Vertex Arrays instead for better, faster rendering */
|
|
|
|
|
GPU_vertex_setup(dm);
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
if(dm->drawObject->tot_triangle_point)
|
|
|
|
|
glDrawArrays(GL_POINTS,0, dm->drawObject->tot_triangle_point);
|
|
|
|
|
else
|
|
|
|
|
glDrawArrays(GL_POINTS,0, dm->drawObject->tot_loose_point);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
GPU_buffer_unbind();
|
|
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_drawUVEdges(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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MFace *mf = cddm->mface;
|
2009-08-15 19:31:28 +02:00
|
|
|
MTFace *tf = DM_get_tessface_data_layer(dm, CD_MTFACE);
|
2006-08-28 03:12:36 +02:00
|
|
|
int i;
|
|
|
|
|
|
2007-04-29 15:39:46 +02:00
|
|
|
if(mf) {
|
2009-10-23 01:22:05 +02:00
|
|
|
if( GPU_buffer_legacy(dm) ) {
|
|
|
|
|
glBegin(GL_LINES);
|
2011-11-30 19:03:56 +01:00
|
|
|
for(i = 0; i < dm->numTessFaceData; i++, mf++, tf++) {
|
2009-10-23 01:22:05 +02:00
|
|
|
if(!(mf->flag&ME_HIDE)) {
|
2006-08-28 03:12:36 +02:00
|
|
|
glVertex2fv(tf->uv[0]);
|
2009-10-23 01:22:05 +02:00
|
|
|
glVertex2fv(tf->uv[1]);
|
|
|
|
|
|
|
|
|
|
glVertex2fv(tf->uv[1]);
|
2006-08-28 03:12:36 +02:00
|
|
|
glVertex2fv(tf->uv[2]);
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(!mf->v4) {
|
|
|
|
|
glVertex2fv(tf->uv[2]);
|
|
|
|
|
glVertex2fv(tf->uv[0]);
|
|
|
|
|
} else {
|
|
|
|
|
glVertex2fv(tf->uv[2]);
|
|
|
|
|
glVertex2fv(tf->uv[3]);
|
|
|
|
|
|
|
|
|
|
glVertex2fv(tf->uv[3]);
|
|
|
|
|
glVertex2fv(tf->uv[0]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
int prevstart = 0;
|
|
|
|
|
int prevdraw = 1;
|
|
|
|
|
int draw = 1;
|
|
|
|
|
int curpos = 0;
|
|
|
|
|
|
|
|
|
|
GPU_uvedge_setup(dm);
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
2011-11-30 19:03:56 +01:00
|
|
|
for(i = 0; i < dm->numTessFaceData; i++, mf++) {
|
2010-11-15 09:03:20 +01:00
|
|
|
if(!(mf->flag&ME_HIDE)) {
|
2009-10-23 01:22:05 +02:00
|
|
|
draw = 1;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
draw = 0;
|
|
|
|
|
}
|
|
|
|
|
if( prevdraw != draw ) {
|
|
|
|
|
if( prevdraw > 0 && (curpos-prevstart) > 0) {
|
|
|
|
|
glDrawArrays(GL_LINES,prevstart,curpos-prevstart);
|
|
|
|
|
}
|
|
|
|
|
prevstart = curpos;
|
|
|
|
|
}
|
|
|
|
|
if( mf->v4 ) {
|
|
|
|
|
curpos += 8;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
curpos += 6;
|
|
|
|
|
}
|
|
|
|
|
prevdraw = draw;
|
|
|
|
|
}
|
|
|
|
|
if( prevdraw > 0 && (curpos-prevstart) > 0 ) {
|
|
|
|
|
glDrawArrays(GL_LINES,prevstart,curpos-prevstart);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
GPU_buffer_unbind();
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-22 12:59:36 +01:00
|
|
|
static void cdDM_drawEdges(DerivedMesh *dm, int drawLooseEdges, int drawAllEdges)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
MEdge *medge = cddm->medge;
|
2006-08-28 03:12:36 +02:00
|
|
|
int i;
|
2009-10-23 01:22:05 +02:00
|
|
|
|
|
|
|
|
if( GPU_buffer_legacy(dm) ) {
|
|
|
|
|
DEBUG_VBO( "Using legacy code. cdDM_drawEdges\n" );
|
|
|
|
|
glBegin(GL_LINES);
|
|
|
|
|
for(i = 0; i < dm->numEdgeData; i++, medge++) {
|
2010-03-22 12:59:36 +01:00
|
|
|
if((drawAllEdges || (medge->flag&ME_EDGEDRAW))
|
2009-10-23 01:22:05 +02:00
|
|
|
&& (drawLooseEdges || !(medge->flag&ME_LOOSEEDGE))) {
|
|
|
|
|
glVertex3fv(mvert[medge->v1].co);
|
|
|
|
|
glVertex3fv(mvert[medge->v2].co);
|
|
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
else { /* use OpenGL VBOs or Vertex Arrays instead for better, faster rendering */
|
|
|
|
|
int prevstart = 0;
|
|
|
|
|
int prevdraw = 1;
|
|
|
|
|
int draw = 1;
|
|
|
|
|
|
|
|
|
|
GPU_edge_setup(dm);
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
|
|
|
|
for(i = 0; i < dm->numEdgeData; i++, medge++) {
|
2010-03-22 12:59:36 +01:00
|
|
|
if((drawAllEdges || (medge->flag&ME_EDGEDRAW))
|
2009-10-23 01:22:05 +02:00
|
|
|
&& (drawLooseEdges || !(medge->flag&ME_LOOSEEDGE))) {
|
|
|
|
|
draw = 1;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
draw = 0;
|
|
|
|
|
}
|
|
|
|
|
if( prevdraw != draw ) {
|
|
|
|
|
if( prevdraw > 0 && (i-prevstart) > 0 ) {
|
2012-03-11 20:09:01 +01:00
|
|
|
GPU_buffer_draw_elements(dm->drawObject->edges, GL_LINES, prevstart * 2, (i - prevstart) * 2);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
prevstart = i;
|
|
|
|
|
}
|
|
|
|
|
prevdraw = draw;
|
|
|
|
|
}
|
|
|
|
|
if( prevdraw > 0 && (i-prevstart) > 0 ) {
|
2012-03-11 20:09:01 +01:00
|
|
|
GPU_buffer_draw_elements(dm->drawObject->edges, GL_LINES, prevstart * 2, (i-prevstart) * 2);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
GPU_buffer_unbind();
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_drawLooseEdges(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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
MEdge *medge = cddm->medge;
|
2006-08-28 03:12:36 +02:00
|
|
|
int i;
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if( GPU_buffer_legacy(dm) ) {
|
|
|
|
|
DEBUG_VBO( "Using legacy code. cdDM_drawLooseEdges\n" );
|
|
|
|
|
glBegin(GL_LINES);
|
|
|
|
|
for(i = 0; i < dm->numEdgeData; i++, medge++) {
|
|
|
|
|
if(medge->flag&ME_LOOSEEDGE) {
|
|
|
|
|
glVertex3fv(mvert[medge->v1].co);
|
|
|
|
|
glVertex3fv(mvert[medge->v2].co);
|
|
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
else { /* use OpenGL VBOs or Vertex Arrays instead for better, faster rendering */
|
|
|
|
|
int prevstart = 0;
|
|
|
|
|
int prevdraw = 1;
|
|
|
|
|
int draw = 1;
|
|
|
|
|
|
|
|
|
|
GPU_edge_setup(dm);
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
|
|
|
|
for(i = 0; i < dm->numEdgeData; i++, medge++) {
|
|
|
|
|
if(medge->flag&ME_LOOSEEDGE) {
|
|
|
|
|
draw = 1;
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
draw = 0;
|
|
|
|
|
}
|
|
|
|
|
if( prevdraw != draw ) {
|
|
|
|
|
if( prevdraw > 0 && (i-prevstart) > 0) {
|
2012-03-11 20:09:01 +01:00
|
|
|
GPU_buffer_draw_elements(dm->drawObject->edges, GL_LINES, prevstart * 2, (i - prevstart) * 2);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
prevstart = i;
|
|
|
|
|
}
|
|
|
|
|
prevdraw = draw;
|
|
|
|
|
}
|
|
|
|
|
if( prevdraw > 0 && (i-prevstart) > 0 ) {
|
2012-03-11 20:09:01 +01:00
|
|
|
GPU_buffer_draw_elements(dm->drawObject->edges, GL_LINES, prevstart * 2, (i - prevstart) * 2);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
GPU_buffer_unbind();
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-28 07:06:05 +01:00
|
|
|
static void cdDM_drawFacesSolid(DerivedMesh *dm,
|
2009-10-27 20:53:34 +01:00
|
|
|
float (*partial_redraw_planes)[4],
|
2012-03-07 05:41:14 +01:00
|
|
|
int UNUSED(fast), DMSetMaterial setMaterial)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
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 12:06:25 +02:00
|
|
|
float *nors= dm->getTessFaceDataArray(dm, CD_NORMAL);
|
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 05:28:02 +01:00
|
|
|
int a, glmode = -1, shademodel = -1, matnr = -1, drawCurrentMat = 1;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
#define PASSVERT(index) { \
|
|
|
|
|
if(shademodel == GL_SMOOTH) { \
|
|
|
|
|
short *no = mvert[index].no; \
|
|
|
|
|
glNormal3sv(no); \
|
|
|
|
|
} \
|
|
|
|
|
glVertex3fv(mvert[index].co); \
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-02 20:04:31 +02:00
|
|
|
if(cddm->pbvh && cddm->pbvh_draw) {
|
2011-11-30 19:03:56 +01:00
|
|
|
if(dm->numTessFaceData) {
|
2010-02-06 18:04:13 +01:00
|
|
|
float (*face_nors)[3] = CustomData_get_layer(&dm->faceData, CD_NORMAL);
|
Sculpt: Multithreading & PBVH Changes
* Sculpting, normal update and bounding box code is now multithreaded
using OpenMP.
* Fix a number of update issues: normals on node boundaries, outdated
bounding boxes, partial redraw, .. . There's probably still a few
left, but should be better now.
* Clicking once now does a single paint instead of two (was also
painting on mouse up event).
* Smooth shading now is enabled for the full mesh when the first face
uses it (so it can be tested at least).
Implementation Notes:
* PBVH search can now be done either using a callback or bt gathering the
nodes in an array. The latter makes multithreading with OpenMP easier.
* Normals update code is now inside PBVH, was doing it per node before but
should do all faces first and only then vertices.
* Instead of using search modes + 1 modified flag, now nodes get 4 flags
to indicate what needs to be updated for them, found that this makes it
easier for me to understand the code and fix update bugs.
* PBVHNode is now exposed as an abstract type, I think this makes it more
clear what is happening than having it's data passed as part of callback
functions.
* Active_verts list was replaced by looping over nodes and the vertices
inside them. However the grab brush still uses the active_verts system,
will fix that later.
* Some micro-optimizations, like avoiding a few multiplications/divisions,
using local variables instead of pointers, or looping over fewer vertices
to update the bounding boxes.
2009-11-02 19:47:03 +01:00
|
|
|
|
2012-03-06 03:40:08 +01:00
|
|
|
BLI_pbvh_draw(cddm->pbvh, partial_redraw_planes, face_nors, setMaterial);
|
2010-02-06 18:04:13 +01:00
|
|
|
glShadeModel(GL_FLAT);
|
|
|
|
|
}
|
Sculpt: Multithreading & PBVH Changes
* Sculpting, normal update and bounding box code is now multithreaded
using OpenMP.
* Fix a number of update issues: normals on node boundaries, outdated
bounding boxes, partial redraw, .. . There's probably still a few
left, but should be better now.
* Clicking once now does a single paint instead of two (was also
painting on mouse up event).
* Smooth shading now is enabled for the full mesh when the first face
uses it (so it can be tested at least).
Implementation Notes:
* PBVH search can now be done either using a callback or bt gathering the
nodes in an array. The latter makes multithreading with OpenMP easier.
* Normals update code is now inside PBVH, was doing it per node before but
should do all faces first and only then vertices.
* Instead of using search modes + 1 modified flag, now nodes get 4 flags
to indicate what needs to be updated for them, found that this makes it
easier for me to understand the code and fix update bugs.
* PBVHNode is now exposed as an abstract type, I think this makes it more
clear what is happening than having it's data passed as part of callback
functions.
* Active_verts list was replaced by looping over nodes and the vertices
inside them. However the grab brush still uses the active_verts system,
will fix that later.
* Some micro-optimizations, like avoiding a few multiplications/divisions,
using local variables instead of pointers, or looping over fewer vertices
to update the bounding boxes.
2009-11-02 19:47:03 +01:00
|
|
|
|
2009-10-27 20:53:34 +01:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if( GPU_buffer_legacy(dm) ) {
|
|
|
|
|
DEBUG_VBO( "Using legacy code. cdDM_drawFacesSolid\n" );
|
|
|
|
|
glBegin(glmode = GL_QUADS);
|
2011-11-30 19:03:56 +01:00
|
|
|
for(a = 0; a < dm->numTessFaceData; a++, mface++) {
|
2009-10-23 01:22:05 +02:00
|
|
|
int new_glmode, new_matnr, new_shademodel;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
new_glmode = mface->v4?GL_QUADS:GL_TRIANGLES;
|
|
|
|
|
new_matnr = mface->mat_nr + 1;
|
|
|
|
|
new_shademodel = (mface->flag & ME_SMOOTH)?GL_SMOOTH:GL_FLAT;
|
|
|
|
|
|
|
|
|
|
if(new_glmode != glmode || new_matnr != matnr
|
|
|
|
|
|| new_shademodel != shademodel) {
|
|
|
|
|
glEnd();
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
drawCurrentMat = setMaterial(matnr = new_matnr, NULL);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glShadeModel(shademodel = new_shademodel);
|
|
|
|
|
glBegin(glmode = new_glmode);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(drawCurrentMat) {
|
|
|
|
|
if(shademodel == GL_FLAT) {
|
|
|
|
|
if (nors) {
|
|
|
|
|
glNormal3fv(nors);
|
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 05:28:02 +01:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
else {
|
|
|
|
|
/* TODO make this better (cache facenormals as layer?) */
|
|
|
|
|
float nor[3];
|
|
|
|
|
if(mface->v4) {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_quad_v3( nor,mvert[mface->v1].co, mvert[mface->v2].co, mvert[mface->v3].co, mvert[mface->v4].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
} else {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_tri_v3( nor,mvert[mface->v1].co, mvert[mface->v2].co, mvert[mface->v3].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
glNormal3fv(nor);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
PASSVERT(mface->v1);
|
|
|
|
|
PASSVERT(mface->v2);
|
|
|
|
|
PASSVERT(mface->v3);
|
|
|
|
|
if(mface->v4) {
|
|
|
|
|
PASSVERT(mface->v4);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(nors) nors += 3;
|
|
|
|
|
}
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
else { /* use OpenGL VBOs or Vertex Arrays instead for better, faster rendering */
|
|
|
|
|
GPU_vertex_setup( dm );
|
|
|
|
|
GPU_normal_setup( dm );
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
|
|
|
|
glShadeModel(GL_SMOOTH);
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
for( a = 0; a < dm->drawObject->totmaterial; a++ ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
if( setMaterial(dm->drawObject->materials[a].mat_nr+1, NULL) )
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
glDrawArrays(GL_TRIANGLES, dm->drawObject->materials[a].start,
|
|
|
|
|
dm->drawObject->materials[a].totpoint);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
GPU_buffer_unbind( );
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#undef PASSVERT
|
2009-10-23 01:22:05 +02:00
|
|
|
glShadeModel(GL_FLAT);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_drawFacesTex_common(DerivedMesh *dm,
|
2012-03-07 05:41:14 +01:00
|
|
|
DMSetDrawOptionsTex drawParams,
|
|
|
|
|
DMSetDrawOptions drawParamsMapped,
|
|
|
|
|
DMCompareDrawOptions compareDrawOptions,
|
2010-03-22 10:30:00 +01:00
|
|
|
void *userData)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mv = cddm->mvert;
|
2009-10-23 01:22:05 +02:00
|
|
|
MFace *mf = DM_get_tessface_data_layer(dm, CD_MFACE);
|
|
|
|
|
MCol *realcol = dm->getTessFaceDataArray(dm, CD_TEXTURE_MCOL);
|
(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 12:06:25 +02:00
|
|
|
float *nors= dm->getTessFaceDataArray(dm, CD_NORMAL);
|
2009-08-15 19:31:28 +02:00
|
|
|
MTFace *tf = DM_get_tessface_data_layer(dm, CD_MTFACE);
|
2011-11-23 21:44:04 +01:00
|
|
|
int i, j, orig, *index = DM_get_tessface_data_layer(dm, CD_ORIGINDEX);
|
2011-12-17 17:22:08 +01:00
|
|
|
int startFace = 0 /*, lastFlag = 0xdeadbeef */ /* UNUSED */;
|
2012-03-22 09:41:50 +01:00
|
|
|
MCol *mcol = dm->getTessFaceDataArray(dm, CD_PREVIEW_MCOL);
|
2009-10-23 01:22:05 +02:00
|
|
|
if(!mcol)
|
|
|
|
|
mcol = dm->getTessFaceDataArray(dm, CD_MCOL);
|
|
|
|
|
|
2010-12-14 04:30:30 +01:00
|
|
|
cdDM_update_normals_from_pbvh(dm);
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if( GPU_buffer_legacy(dm) ) {
|
|
|
|
|
DEBUG_VBO( "Using legacy code. cdDM_drawFacesTex_common\n" );
|
2011-11-30 19:03:56 +01:00
|
|
|
for(i = 0; i < dm->numTessFaceData; i++, mf++) {
|
2009-10-23 01:22:05 +02:00
|
|
|
MVert *mvert;
|
2012-03-08 07:47:05 +01:00
|
|
|
DMDrawOption draw_option;
|
2009-10-23 01:22:05 +02:00
|
|
|
unsigned char *cp = NULL;
|
|
|
|
|
|
|
|
|
|
if(drawParams) {
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option = drawParams(tf? &tf[i]: NULL, (mcol != NULL), mf->mat_nr);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
if(index) {
|
|
|
|
|
orig = *index++;
|
|
|
|
|
if(orig == ORIGINDEX_NONE) { if(nors) nors += 3; continue; }
|
2012-03-08 07:47:05 +01:00
|
|
|
if(drawParamsMapped) draw_option = drawParamsMapped(userData, orig);
|
2009-10-23 01:22:05 +02:00
|
|
|
else { if(nors) nors += 3; continue; }
|
|
|
|
|
}
|
|
|
|
|
else
|
2012-03-08 07:47:05 +01:00
|
|
|
if(drawParamsMapped) draw_option = drawParamsMapped(userData, i);
|
2009-10-23 01:22:05 +02:00
|
|
|
else { if(nors) nors += 3; continue; }
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-08 07:47:05 +01:00
|
|
|
if(draw_option != DM_DRAW_OPTION_SKIP) {
|
|
|
|
|
if (draw_option != DM_DRAW_OPTION_NO_MCOL && mcol)
|
2009-10-23 01:22:05 +02:00
|
|
|
cp= (unsigned char*) &mcol[i*4];
|
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 05:28:02 +01:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(!(mf->flag&ME_SMOOTH)) {
|
|
|
|
|
if (nors) {
|
|
|
|
|
glNormal3fv(nors);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
float nor[3];
|
|
|
|
|
if(mf->v4) {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_quad_v3( nor,mv[mf->v1].co, mv[mf->v2].co, mv[mf->v3].co, mv[mf->v4].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
} else {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_tri_v3( nor,mv[mf->v1].co, mv[mf->v2].co, mv[mf->v3].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
glNormal3fv(nor);
|
|
|
|
|
}
|
|
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glBegin(mf->v4?GL_QUADS:GL_TRIANGLES);
|
|
|
|
|
if(tf) glTexCoord2fv(tf[i].uv[0]);
|
|
|
|
|
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
|
|
|
|
|
mvert = &mv[mf->v1];
|
|
|
|
|
if(mf->flag&ME_SMOOTH) glNormal3sv(mvert->no);
|
|
|
|
|
glVertex3fv(mvert->co);
|
|
|
|
|
|
|
|
|
|
if(tf) glTexCoord2fv(tf[i].uv[1]);
|
|
|
|
|
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
|
|
|
|
|
mvert = &mv[mf->v2];
|
|
|
|
|
if(mf->flag&ME_SMOOTH) glNormal3sv(mvert->no);
|
|
|
|
|
glVertex3fv(mvert->co);
|
|
|
|
|
|
|
|
|
|
if(tf) glTexCoord2fv(tf[i].uv[2]);
|
|
|
|
|
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
|
|
|
|
|
mvert = &mv[mf->v3];
|
|
|
|
|
if(mf->flag&ME_SMOOTH) glNormal3sv(mvert->no);
|
|
|
|
|
glVertex3fv(mvert->co);
|
|
|
|
|
|
|
|
|
|
if(mf->v4) {
|
|
|
|
|
if(tf) glTexCoord2fv(tf[i].uv[3]);
|
|
|
|
|
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
|
|
|
|
|
mvert = &mv[mf->v4];
|
|
|
|
|
if(mf->flag&ME_SMOOTH) glNormal3sv(mvert->no);
|
|
|
|
|
glVertex3fv(mvert->co);
|
|
|
|
|
}
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(nors) nors += 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 05:28:02 +01:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
} else { /* use OpenGL VBOs or Vertex Arrays instead for better, faster rendering */
|
|
|
|
|
MCol *col = realcol;
|
|
|
|
|
if(!col)
|
|
|
|
|
col = mcol;
|
|
|
|
|
|
|
|
|
|
GPU_vertex_setup( dm );
|
|
|
|
|
GPU_normal_setup( dm );
|
|
|
|
|
GPU_uv_setup( dm );
|
2011-02-13 11:52:18 +01:00
|
|
|
if( col != NULL ) {
|
2012-02-27 11:35:39 +01:00
|
|
|
/*if( realcol && dm->drawObject->colType == CD_TEXTURE_MCOL ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
col = 0;
|
|
|
|
|
} else if( mcol && dm->drawObject->colType == CD_MCOL ) {
|
|
|
|
|
col = 0;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
|
|
|
|
|
if( col != 0 ) {*/
|
|
|
|
|
unsigned char *colors = MEM_mallocN(dm->getNumTessFaces(dm)*4*3*sizeof(unsigned char), "cdDM_drawFacesTex_common");
|
|
|
|
|
for( i=0; i < dm->getNumTessFaces(dm); i++ ) {
|
|
|
|
|
for( j=0; j < 4; j++ ) {
|
2011-10-10 02:01:44 +02:00
|
|
|
/* bgr -> rgb is intentional (and stupid), but how its stored internally */
|
|
|
|
|
colors[i*12+j*3] = col[i*4+j].b;
|
2009-10-23 01:22:05 +02:00
|
|
|
colors[i*12+j*3+1] = col[i*4+j].g;
|
2011-10-10 02:01:44 +02:00
|
|
|
colors[i*12+j*3+2] = col[i*4+j].r;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
GPU_color3_upload(dm,colors);
|
|
|
|
|
MEM_freeN(colors);
|
|
|
|
|
if(realcol)
|
|
|
|
|
dm->drawObject->colType = CD_TEXTURE_MCOL;
|
|
|
|
|
else if(mcol)
|
|
|
|
|
dm->drawObject->colType = CD_MCOL;
|
|
|
|
|
//}
|
|
|
|
|
GPU_color_setup( dm );
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
2011-12-01 13:12:39 +01:00
|
|
|
int tottri = dm->drawObject->tot_triangle_point/3;
|
|
|
|
|
int next_actualFace= dm->drawObject->triangle_to_mface[0];
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glShadeModel( GL_SMOOTH );
|
2011-12-17 17:22:08 +01:00
|
|
|
/* lastFlag = 0; */ /* UNUSED */
|
2011-12-01 13:12:39 +01:00
|
|
|
for(i = 0; i < tottri; i++) {
|
|
|
|
|
int actualFace = next_actualFace;
|
2012-03-08 07:47:05 +01:00
|
|
|
DMDrawOption draw_option = DM_DRAW_OPTION_NORMAL;
|
2011-12-01 13:12:39 +01:00
|
|
|
int flush = 0;
|
|
|
|
|
|
|
|
|
|
if(i != tottri-1)
|
|
|
|
|
next_actualFace= dm->drawObject->triangle_to_mface[i+1];
|
2009-10-23 01:22:05 +02:00
|
|
|
|
|
|
|
|
if(drawParams) {
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option = drawParams(tf? &tf[actualFace]: NULL, (mcol != NULL), mf[actualFace].mat_nr);
|
2007-04-29 15:39:46 +02:00
|
|
|
}
|
|
|
|
|
else {
|
2009-10-23 01:22:05 +02:00
|
|
|
if(index) {
|
|
|
|
|
orig = index[actualFace];
|
2010-12-26 14:01:02 +01:00
|
|
|
if(orig == ORIGINDEX_NONE) continue;
|
2009-10-23 01:22:05 +02:00
|
|
|
if(drawParamsMapped)
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option = drawParamsMapped(userData, orig);
|
2007-04-29 15:39:46 +02:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
else
|
|
|
|
|
if(drawParamsMapped)
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option = drawParamsMapped(userData, actualFace);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
2011-12-01 13:12:39 +01:00
|
|
|
|
|
|
|
|
/* flush buffer if current triangle isn't drawable or it's last triangle */
|
2012-03-08 07:47:05 +01:00
|
|
|
flush= (draw_option == DM_DRAW_OPTION_SKIP) || (i == tottri - 1);
|
2011-12-01 13:12:39 +01:00
|
|
|
|
|
|
|
|
if(!flush && compareDrawOptions) {
|
2011-12-01 19:26:48 +01:00
|
|
|
/* also compare draw options and flush buffer if they're different
|
2012-03-09 19:28:30 +01:00
|
|
|
* need for face selection highlight in edit mode */
|
2011-12-01 19:26:48 +01:00
|
|
|
flush|= compareDrawOptions(userData, actualFace, next_actualFace) == 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 05:28:02 +01:00
|
|
|
}
|
2011-12-01 13:12:39 +01:00
|
|
|
|
|
|
|
|
if(flush) {
|
|
|
|
|
int first= startFace*3;
|
2012-03-08 07:47:05 +01:00
|
|
|
/* Add one to the length if we're drawing at the end of the array */
|
|
|
|
|
int count= (i-startFace+(draw_option != DM_DRAW_OPTION_SKIP ? 1 : 0))*3;
|
2011-12-01 13:12:39 +01:00
|
|
|
|
|
|
|
|
if(count) {
|
|
|
|
|
if (col)
|
|
|
|
|
GPU_color_switch(1);
|
|
|
|
|
else
|
|
|
|
|
GPU_color_switch(0);
|
|
|
|
|
|
|
|
|
|
glDrawArrays(GL_TRIANGLES, first, count);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
startFace = i + 1;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
2007-04-29 15:39:46 +02:00
|
|
|
}
|
|
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
|
|
|
|
|
GPU_buffer_unbind();
|
|
|
|
|
glShadeModel( GL_FLAT );
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-01 13:12:39 +01:00
|
|
|
static void cdDM_drawFacesTex(DerivedMesh *dm,
|
2012-03-07 05:41:14 +01:00
|
|
|
DMSetDrawOptionsTex setDrawOptions,
|
|
|
|
|
DMCompareDrawOptions compareDrawOptions,
|
2011-12-01 13:12:39 +01:00
|
|
|
void *userData)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2011-12-01 13:12:39 +01:00
|
|
|
cdDM_drawFacesTex_common(dm, setDrawOptions, NULL, compareDrawOptions, userData);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-12-01 13:12:39 +01:00
|
|
|
static void cdDM_drawMappedFaces(DerivedMesh *dm,
|
2012-03-07 13:48:52 +01:00
|
|
|
DMSetDrawOptions setDrawOptions,
|
2012-03-07 05:41:14 +01:00
|
|
|
DMSetMaterial setMaterial,
|
|
|
|
|
DMCompareDrawOptions compareDrawOptions,
|
2012-03-07 13:48:52 +01:00
|
|
|
void *userData, DMDrawFlag flag)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mv = cddm->mvert;
|
|
|
|
|
MFace *mf = cddm->mface;
|
2009-05-23 05:24:15 +02:00
|
|
|
MCol *mc;
|
2011-06-01 21:30:19 +02:00
|
|
|
float *nors= DM_get_tessface_data_layer(dm, CD_NORMAL);
|
2012-03-07 13:48:52 +01:00
|
|
|
int useColors = flag & DM_DRAW_USE_COLORS;
|
2011-11-23 21:44:04 +01:00
|
|
|
int i, orig, *index = DM_get_tessface_data_layer(dm, CD_ORIGINDEX);
|
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 05:28:02 +01:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
mc = DM_get_tessface_data_layer(dm, CD_ID_MCOL);
|
|
|
|
|
if(!mc)
|
2012-03-22 09:41:50 +01:00
|
|
|
mc = DM_get_tessface_data_layer(dm, CD_PREVIEW_MCOL);
|
2009-05-23 05:24:15 +02:00
|
|
|
if(!mc)
|
2009-08-15 19:31:28 +02:00
|
|
|
mc = DM_get_tessface_data_layer(dm, CD_MCOL);
|
2009-05-23 05:24:15 +02:00
|
|
|
|
2010-12-14 04:30:30 +01:00
|
|
|
cdDM_update_normals_from_pbvh(dm);
|
|
|
|
|
|
2010-02-05 14:38:41 +01:00
|
|
|
/* back-buffer always uses legacy since VBO's would need the
|
|
|
|
|
* color array temporarily overwritten for drawing, then reset. */
|
|
|
|
|
if( GPU_buffer_legacy(dm) || G.f & G_BACKBUFSEL) {
|
2009-10-23 01:22:05 +02:00
|
|
|
DEBUG_VBO( "Using legacy code. cdDM_drawMappedFaces\n" );
|
2011-11-30 19:03:56 +01:00
|
|
|
for(i = 0; i < dm->numTessFaceData; i++, mf++) {
|
2012-03-07 13:48:52 +01:00
|
|
|
int drawSmooth = (flag & DM_DRAW_ALWAYS_SMOOTH) ? 1 : (mf->flag & ME_SMOOTH);
|
2012-03-08 07:47:05 +01:00
|
|
|
DMDrawOption draw_option= DM_DRAW_OPTION_NORMAL;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2010-10-05 13:25:34 +02:00
|
|
|
orig= (index==NULL) ? i : *index++;
|
2011-11-30 07:27:38 +01:00
|
|
|
|
|
|
|
|
if(orig == ORIGINDEX_NONE)
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option= setMaterial(mf->mat_nr + 1, NULL);
|
2011-11-30 07:27:38 +01:00
|
|
|
else if (setDrawOptions != NULL)
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option= setDrawOptions(userData, orig);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2012-03-08 07:47:05 +01:00
|
|
|
if(draw_option != DM_DRAW_OPTION_SKIP) {
|
2009-10-23 01:22:05 +02:00
|
|
|
unsigned char *cp = NULL;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(useColors && mc)
|
|
|
|
|
cp = (unsigned char *)&mc[i * 4];
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2011-11-10 11:24:34 +01:00
|
|
|
/* no need to set shading mode to flat because
|
2012-03-09 19:28:30 +01:00
|
|
|
* normals are already used to change shading */
|
2011-06-16 12:41:00 +02:00
|
|
|
glShadeModel(GL_SMOOTH);
|
2009-10-23 01:22:05 +02:00
|
|
|
glBegin(mf->v4?GL_QUADS:GL_TRIANGLES);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if (!drawSmooth) {
|
|
|
|
|
if (nors) {
|
|
|
|
|
glNormal3fv(nors);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
float nor[3];
|
|
|
|
|
if(mf->v4) {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_quad_v3( nor,mv[mf->v1].co, mv[mf->v2].co, mv[mf->v3].co, mv[mf->v4].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
} else {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_tri_v3( nor,mv[mf->v1].co, mv[mf->v2].co, mv[mf->v3].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
glNormal3fv(nor);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
|
|
|
|
|
glVertex3fv(mv[mf->v1].co);
|
|
|
|
|
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
|
|
|
|
|
glVertex3fv(mv[mf->v2].co);
|
|
|
|
|
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
|
|
|
|
|
glVertex3fv(mv[mf->v3].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 05:28:02 +01:00
|
|
|
if(mf->v4) {
|
2009-10-23 01:22:05 +02:00
|
|
|
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
|
|
|
|
|
glVertex3fv(mv[mf->v4].co);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
|
|
|
|
|
glNormal3sv(mv[mf->v1].no);
|
|
|
|
|
glVertex3fv(mv[mf->v1].co);
|
|
|
|
|
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
|
|
|
|
|
glNormal3sv(mv[mf->v2].no);
|
|
|
|
|
glVertex3fv(mv[mf->v2].co);
|
|
|
|
|
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
|
|
|
|
|
glNormal3sv(mv[mf->v3].no);
|
|
|
|
|
glVertex3fv(mv[mf->v3].co);
|
|
|
|
|
if(mf->v4) {
|
|
|
|
|
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
|
|
|
|
|
glNormal3sv(mv[mf->v4].no);
|
|
|
|
|
glVertex3fv(mv[mf->v4].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 05:28:02 +01:00
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glEnd();
|
2011-12-05 00:13:28 +01:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
|
|
|
|
|
if (nors) nors += 3;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
else { /* use OpenGL VBOs or Vertex Arrays instead for better, faster rendering */
|
|
|
|
|
int prevstart = 0;
|
|
|
|
|
GPU_vertex_setup(dm);
|
|
|
|
|
GPU_normal_setup(dm);
|
|
|
|
|
if( useColors && mc )
|
|
|
|
|
GPU_color_setup(dm);
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
int tottri = dm->drawObject->tot_triangle_point/3;
|
2009-10-23 01:22:05 +02:00
|
|
|
glShadeModel(GL_SMOOTH);
|
2010-10-04 21:01:25 +02:00
|
|
|
|
|
|
|
|
if(tottri == 0) {
|
|
|
|
|
/* avoid buffer problems in following code */
|
|
|
|
|
}
|
|
|
|
|
if(setDrawOptions == NULL) {
|
|
|
|
|
/* just draw the entire face array */
|
2011-11-14 17:34:11 +01:00
|
|
|
glDrawArrays(GL_TRIANGLES, 0, (tottri) * 3);
|
2010-10-04 21:01:25 +02:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* we need to check if the next material changes */
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
int next_actualFace= dm->drawObject->triangle_to_mface[0];
|
2010-10-04 21:01:25 +02:00
|
|
|
|
|
|
|
|
for( i = 0; i < tottri; i++ ) {
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
//int actualFace = dm->drawObject->triangle_to_mface[i];
|
2010-10-04 21:01:25 +02:00
|
|
|
int actualFace = next_actualFace;
|
2010-10-05 13:25:34 +02:00
|
|
|
MFace *mface= mf + actualFace;
|
2012-03-07 13:48:52 +01:00
|
|
|
/*int drawSmooth= (flag & DM_DRAW_ALWAYS_SMOOTH) ? 1 : (mface->flag & ME_SMOOTH);*/ /* UNUSED */
|
2012-03-08 07:47:05 +01:00
|
|
|
DMDrawOption draw_option = DM_DRAW_OPTION_NORMAL;
|
2011-08-29 18:07:44 +02:00
|
|
|
int flush = 0;
|
2010-10-04 21:01:25 +02:00
|
|
|
|
|
|
|
|
if(i != tottri-1)
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
next_actualFace= dm->drawObject->triangle_to_mface[i+1];
|
2010-10-05 13:25:34 +02:00
|
|
|
|
|
|
|
|
orig= (index==NULL) ? actualFace : index[actualFace];
|
|
|
|
|
|
2011-11-30 07:27:38 +01:00
|
|
|
if(orig == ORIGINDEX_NONE)
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option= setMaterial(mface->mat_nr + 1, NULL);
|
2011-11-30 07:27:38 +01:00
|
|
|
else if (setDrawOptions != NULL)
|
2012-03-08 07:47:05 +01:00
|
|
|
draw_option= setDrawOptions(userData, orig);
|
2010-10-04 21:01:25 +02:00
|
|
|
|
|
|
|
|
/* Goal is to draw as long of a contiguous triangle
|
2012-03-09 19:28:30 +01:00
|
|
|
* array as possible, so draw when we hit either an
|
|
|
|
|
* invisible triangle or at the end of the array */
|
2011-08-29 18:07:44 +02:00
|
|
|
|
|
|
|
|
/* flush buffer if current triangle isn't drawable or it's last triangle... */
|
2012-03-08 07:47:05 +01:00
|
|
|
flush= (draw_option == DM_DRAW_OPTION_SKIP) || (i == tottri - 1);
|
2011-08-29 18:07:44 +02:00
|
|
|
|
|
|
|
|
/* ... or when material setting is dissferent */
|
|
|
|
|
flush|= mf[actualFace].mat_nr != mf[next_actualFace].mat_nr;
|
|
|
|
|
|
|
|
|
|
if(!flush && compareDrawOptions) {
|
2011-12-01 19:26:48 +01:00
|
|
|
flush|= compareDrawOptions(userData, actualFace, next_actualFace) == 0;
|
2011-08-29 18:07:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(flush) {
|
|
|
|
|
int first= prevstart*3;
|
2012-03-08 07:47:05 +01:00
|
|
|
/* Add one to the length if we're drawing at the end of the array */
|
|
|
|
|
int count= (i-prevstart+(draw_option != DM_DRAW_OPTION_SKIP ? 1 : 0))*3;
|
2011-08-29 18:07:44 +02:00
|
|
|
|
|
|
|
|
if(count)
|
|
|
|
|
glDrawArrays(GL_TRIANGLES, first, count);
|
|
|
|
|
|
2010-10-04 21:01:25 +02:00
|
|
|
prevstart = i + 1;
|
|
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
2010-10-04 21:01:25 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glShadeModel(GL_FLAT);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
GPU_buffer_unbind();
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-01 13:12:39 +01:00
|
|
|
static void cdDM_drawMappedFacesTex(DerivedMesh *dm,
|
2012-03-07 05:41:14 +01:00
|
|
|
DMSetDrawOptions setDrawOptions,
|
|
|
|
|
DMCompareDrawOptions compareDrawOptions,
|
2011-12-01 13:12:39 +01:00
|
|
|
void *userData)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2011-12-01 13:12:39 +01:00
|
|
|
cdDM_drawFacesTex_common(dm, NULL, setDrawOptions, compareDrawOptions, userData);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-08-12 20:17:28 +02:00
|
|
|
static void cddm_draw_attrib_vertex(DMVertexAttribs *attribs, MVert *mvert, int a, int index, int vert, int smoothnormal)
|
|
|
|
|
{
|
|
|
|
|
int b;
|
|
|
|
|
|
|
|
|
|
/* orco texture coordinates */
|
|
|
|
|
if(attribs->totorco) {
|
|
|
|
|
if(attribs->orco.glTexco)
|
|
|
|
|
glTexCoord3fv(attribs->orco.array[index]);
|
|
|
|
|
else
|
|
|
|
|
glVertexAttrib3fvARB(attribs->orco.glIndex, attribs->orco.array[index]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* uv texture coordinates */
|
|
|
|
|
for(b = 0; b < attribs->tottface; b++) {
|
|
|
|
|
MTFace *tf = &attribs->tface[b].array[a];
|
|
|
|
|
|
|
|
|
|
if(attribs->tface[b].glTexco)
|
|
|
|
|
glTexCoord2fv(tf->uv[vert]);
|
|
|
|
|
else
|
|
|
|
|
glVertexAttrib2fvARB(attribs->tface[b].glIndex, tf->uv[vert]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* vertex colors */
|
|
|
|
|
for(b = 0; b < attribs->totmcol; b++) {
|
|
|
|
|
MCol *cp = &attribs->mcol[b].array[a*4 + vert];
|
|
|
|
|
GLubyte col[4];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
|
|
|
|
glVertexAttrib4ubvARB(attribs->mcol[b].glIndex, col);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* tangent for normal mapping */
|
|
|
|
|
if(attribs->tottang) {
|
|
|
|
|
float *tang = attribs->tang.array[a*4 + vert];
|
|
|
|
|
glVertexAttrib4fvARB(attribs->tang.glIndex, tang);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* vertex normal */
|
|
|
|
|
if(smoothnormal)
|
|
|
|
|
glNormal3sv(mvert[index].no);
|
|
|
|
|
|
|
|
|
|
/* vertex coordinate */
|
|
|
|
|
glVertex3fv(mvert[index].co);
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-01 13:12:39 +01:00
|
|
|
static void cdDM_drawMappedFacesGLSL(DerivedMesh *dm,
|
2012-03-07 05:41:14 +01:00
|
|
|
DMSetMaterial setMaterial,
|
|
|
|
|
DMSetDrawOptions setDrawOptions,
|
2011-12-01 13:12:39 +01:00
|
|
|
void *userData)
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
GPUVertexAttribs gattribs;
|
|
|
|
|
DMVertexAttribs attribs;
|
|
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
MFace *mface = cddm->mface;
|
2011-09-23 08:18:03 +02:00
|
|
|
/* MTFace *tf = dm->getTessFaceDataArray(dm, CD_MTFACE); */ /* UNUSED */
|
(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 12:06:25 +02:00
|
|
|
float (*nors)[3] = dm->getTessFaceDataArray(dm, CD_NORMAL);
|
2011-01-14 22:06:28 +01:00
|
|
|
int a, b, dodraw, matnr, new_matnr;
|
2011-11-23 21:44:04 +01:00
|
|
|
int orig, *index = dm->getTessFaceDataArray(dm, CD_ORIGINDEX);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2010-12-14 04:30:30 +01:00
|
|
|
cdDM_update_normals_from_pbvh(dm);
|
|
|
|
|
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
matnr = -1;
|
|
|
|
|
dodraw = 0;
|
|
|
|
|
|
|
|
|
|
glShadeModel(GL_SMOOTH);
|
|
|
|
|
|
2011-02-13 11:52:18 +01:00
|
|
|
if( GPU_buffer_legacy(dm) || setDrawOptions != NULL ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
DEBUG_VBO( "Using legacy code. cdDM_drawMappedFacesGLSL\n" );
|
|
|
|
|
memset(&attribs, 0, sizeof(attribs));
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glBegin(GL_QUADS);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
for(a = 0; a < dm->numTessFaceData; a++, mface++) {
|
2011-01-14 22:06:28 +01:00
|
|
|
const int smoothnormal = (mface->flag & ME_SMOOTH);
|
2009-10-23 01:22:05 +02:00
|
|
|
new_matnr = mface->mat_nr + 1;
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(new_matnr != matnr) {
|
|
|
|
|
glEnd();
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
dodraw = setMaterial(matnr = new_matnr, &gattribs);
|
|
|
|
|
if(dodraw)
|
|
|
|
|
DM_vertex_attributes_from_gpu(dm, &gattribs, &attribs);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glBegin(GL_QUADS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(!dodraw) {
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
continue;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
else if(setDrawOptions) {
|
2009-11-04 21:23:48 +01:00
|
|
|
orig = (index)? index[a]: a;
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2010-10-05 13:25:34 +02:00
|
|
|
if(orig == ORIGINDEX_NONE) {
|
|
|
|
|
/* since the material is set by setMaterial(), faces with no
|
|
|
|
|
* origin can be assumed to be generated by a modifier */
|
|
|
|
|
|
|
|
|
|
/* continue */
|
|
|
|
|
}
|
2012-03-08 07:47:05 +01:00
|
|
|
else if(setDrawOptions(userData, orig) == DM_DRAW_OPTION_SKIP)
|
2009-10-23 01:22:05 +02:00
|
|
|
continue;
|
|
|
|
|
}
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(!smoothnormal) {
|
|
|
|
|
if(nors) {
|
|
|
|
|
glNormal3fv(nors[a]);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* TODO ideally a normal layer should always be available */
|
|
|
|
|
float nor[3];
|
|
|
|
|
if(mface->v4) {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_quad_v3( nor,mvert[mface->v1].co, mvert[mface->v2].co, mvert[mface->v3].co, mvert[mface->v4].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
} else {
|
2009-11-10 21:43:45 +01:00
|
|
|
normal_tri_v3( nor,mvert[mface->v1].co, mvert[mface->v2].co, mvert[mface->v3].co);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
glNormal3fv(nor);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-08-12 20:17:28 +02:00
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mface->v1, 0, smoothnormal);
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mface->v2, 1, smoothnormal);
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mface->v3, 2, smoothnormal);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
if(mface->v4)
|
2011-08-12 20:17:28 +02:00
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mface->v4, 3, smoothnormal);
|
2009-10-23 01:22:05 +02:00
|
|
|
else
|
2011-08-12 20:17:28 +02:00
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mface->v3, 2, smoothnormal);
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
else {
|
2011-02-13 11:52:18 +01:00
|
|
|
GPUBuffer *buffer = NULL;
|
|
|
|
|
char *varray = NULL;
|
2009-10-23 01:22:05 +02:00
|
|
|
int numdata = 0, elementsize = 0, offset;
|
2011-09-20 10:48:48 +02:00
|
|
|
int start = 0, numfaces = 0 /* , prevdraw = 0 */ /* UNUSED */, curface = 0;
|
2010-02-15 13:35:32 +01:00
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
MFace *mf = mface;
|
2010-02-09 19:06:57 +01:00
|
|
|
GPUAttrib datatypes[GPU_MAX_ATTRIB]; /* TODO, messing up when switching materials many times - [#21056]*/
|
2009-10-23 01:22:05 +02:00
|
|
|
memset(&attribs, 0, sizeof(attribs));
|
|
|
|
|
|
|
|
|
|
GPU_vertex_setup(dm);
|
|
|
|
|
GPU_normal_setup(dm);
|
|
|
|
|
|
|
|
|
|
if( !GPU_buffer_legacy(dm) ) {
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
for( i = 0; i < dm->drawObject->tot_triangle_point/3; i++ ) {
|
2010-02-15 13:35:32 +01:00
|
|
|
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
a = dm->drawObject->triangle_to_mface[i];
|
2010-02-15 13:35:32 +01:00
|
|
|
|
|
|
|
|
mface = mf + a;
|
2009-10-23 01:22:05 +02:00
|
|
|
new_matnr = mface->mat_nr + 1;
|
|
|
|
|
|
|
|
|
|
if(new_matnr != matnr ) {
|
|
|
|
|
numfaces = curface - start;
|
|
|
|
|
if( numfaces > 0 ) {
|
2010-02-15 13:35:32 +01:00
|
|
|
|
|
|
|
|
if( dodraw ) {
|
|
|
|
|
|
|
|
|
|
if( numdata != 0 ) {
|
|
|
|
|
|
|
|
|
|
GPU_buffer_unlock(buffer);
|
|
|
|
|
|
|
|
|
|
GPU_interleaved_attrib_setup(buffer,datatypes,numdata);
|
|
|
|
|
}
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
glDrawArrays(GL_TRIANGLES,start*3,numfaces*3);
|
2010-02-15 13:35:32 +01:00
|
|
|
|
|
|
|
|
if( numdata != 0 ) {
|
|
|
|
|
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
GPU_buffer_free(buffer);
|
2010-02-15 13:35:32 +01:00
|
|
|
|
2011-02-13 11:52:18 +01:00
|
|
|
buffer = NULL;
|
2010-02-15 13:35:32 +01:00
|
|
|
}
|
|
|
|
|
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
2010-02-11 22:55:07 +01:00
|
|
|
numdata = 0;
|
2009-10-23 01:22:05 +02:00
|
|
|
start = curface;
|
2011-09-20 10:48:48 +02:00
|
|
|
/* prevdraw = dodraw; */ /* UNUSED */
|
2009-10-23 01:22:05 +02:00
|
|
|
dodraw = setMaterial(matnr = new_matnr, &gattribs);
|
|
|
|
|
if(dodraw) {
|
|
|
|
|
DM_vertex_attributes_from_gpu(dm, &gattribs, &attribs);
|
|
|
|
|
|
|
|
|
|
if(attribs.totorco) {
|
|
|
|
|
datatypes[numdata].index = attribs.orco.glIndex;
|
|
|
|
|
datatypes[numdata].size = 3;
|
|
|
|
|
datatypes[numdata].type = GL_FLOAT;
|
|
|
|
|
numdata++;
|
|
|
|
|
}
|
|
|
|
|
for(b = 0; b < attribs.tottface; b++) {
|
|
|
|
|
datatypes[numdata].index = attribs.tface[b].glIndex;
|
|
|
|
|
datatypes[numdata].size = 2;
|
|
|
|
|
datatypes[numdata].type = GL_FLOAT;
|
|
|
|
|
numdata++;
|
|
|
|
|
}
|
|
|
|
|
for(b = 0; b < attribs.totmcol; b++) {
|
|
|
|
|
datatypes[numdata].index = attribs.mcol[b].glIndex;
|
|
|
|
|
datatypes[numdata].size = 4;
|
|
|
|
|
datatypes[numdata].type = GL_UNSIGNED_BYTE;
|
|
|
|
|
numdata++;
|
|
|
|
|
}
|
|
|
|
|
if(attribs.tottang) {
|
|
|
|
|
datatypes[numdata].index = attribs.tang.glIndex;
|
2011-02-14 19:18:46 +01:00
|
|
|
datatypes[numdata].size = 4;
|
2009-10-23 01:22:05 +02:00
|
|
|
datatypes[numdata].type = GL_FLOAT;
|
|
|
|
|
numdata++;
|
|
|
|
|
}
|
|
|
|
|
if( numdata != 0 ) {
|
|
|
|
|
elementsize = GPU_attrib_element_size( datatypes, numdata );
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
buffer = GPU_buffer_alloc( elementsize*dm->drawObject->tot_triangle_point);
|
2011-02-13 11:52:18 +01:00
|
|
|
if( buffer == NULL ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
GPU_buffer_unbind();
|
|
|
|
|
dm->drawObject->legacy = 1;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
varray = GPU_buffer_lock_stream(buffer);
|
2011-02-13 11:52:18 +01:00
|
|
|
if( varray == NULL ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
GPU_buffer_unbind();
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
GPU_buffer_free(buffer);
|
2009-10-23 01:22:05 +02:00
|
|
|
dm->drawObject->legacy = 1;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
2010-02-08 22:33:47 +01:00
|
|
|
else {
|
2012-03-18 08:38:51 +01:00
|
|
|
/* if the buffer was set, don't use it again.
|
2010-02-08 22:33:47 +01:00
|
|
|
* prevdraw was assumed true but didnt run so set to false - [#21036] */
|
2011-09-20 10:48:48 +02:00
|
|
|
/* prevdraw= 0; */ /* UNUSED */
|
2010-02-08 22:33:47 +01:00
|
|
|
buffer= NULL;
|
|
|
|
|
}
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-12-07 23:03:49 +01:00
|
|
|
if(dodraw && numdata != 0 ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
offset = 0;
|
|
|
|
|
if(attribs.totorco) {
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v3_v3((float *)&varray[elementsize*curface*3],(float *)attribs.orco.array[mface->v1]);
|
|
|
|
|
copy_v3_v3((float *)&varray[elementsize*curface*3+elementsize],(float *)attribs.orco.array[mface->v2]);
|
|
|
|
|
copy_v3_v3((float *)&varray[elementsize*curface*3+elementsize*2],(float *)attribs.orco.array[mface->v3]);
|
2009-10-23 01:22:05 +02:00
|
|
|
offset += sizeof(float)*3;
|
|
|
|
|
}
|
|
|
|
|
for(b = 0; b < attribs.tottface; b++) {
|
|
|
|
|
MTFace *tf = &attribs.tface[b].array[a];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v2_v2((float *)&varray[elementsize*curface*3+offset],tf->uv[0]);
|
|
|
|
|
copy_v2_v2((float *)&varray[elementsize*curface*3+offset+elementsize],tf->uv[1]);
|
2010-02-15 13:35:32 +01:00
|
|
|
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v2_v2((float *)&varray[elementsize*curface*3+offset+elementsize*2],tf->uv[2]);
|
2009-10-23 01:22:05 +02:00
|
|
|
offset += sizeof(float)*2;
|
|
|
|
|
}
|
|
|
|
|
for(b = 0; b < attribs.totmcol; b++) {
|
|
|
|
|
MCol *cp = &attribs.mcol[b].array[a*4 + 0];
|
|
|
|
|
GLubyte col[4];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4_char((char *)&varray[elementsize*curface*3+offset], (char *)col);
|
2009-10-23 01:22:05 +02:00
|
|
|
cp = &attribs.mcol[b].array[a*4 + 1];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4_char((char *)&varray[elementsize*curface*3+offset+elementsize], (char *)col);
|
2009-10-23 01:22:05 +02:00
|
|
|
cp = &attribs.mcol[b].array[a*4 + 2];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4_char((char *)&varray[elementsize*curface*3+offset+elementsize*2], (char *)col);
|
2009-10-23 01:22:05 +02:00
|
|
|
offset += sizeof(unsigned char)*4;
|
|
|
|
|
}
|
|
|
|
|
if(attribs.tottang) {
|
|
|
|
|
float *tang = attribs.tang.array[a*4 + 0];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4((float *)&varray[elementsize*curface*3+offset], tang);
|
2009-10-23 01:22:05 +02:00
|
|
|
tang = attribs.tang.array[a*4 + 1];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4((float *)&varray[elementsize*curface*3+offset+elementsize], tang);
|
2009-10-23 01:22:05 +02:00
|
|
|
tang = attribs.tang.array[a*4 + 2];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4((float *)&varray[elementsize*curface*3+offset+elementsize*2], tang);
|
2011-02-14 19:18:46 +01:00
|
|
|
offset += sizeof(float)*4;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
2011-07-27 15:03:56 +02:00
|
|
|
(void)offset;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
curface++;
|
|
|
|
|
if(mface->v4) {
|
2011-12-07 23:03:49 +01:00
|
|
|
if(dodraw && numdata != 0 ) {
|
2009-10-23 01:22:05 +02:00
|
|
|
offset = 0;
|
|
|
|
|
if(attribs.totorco) {
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v3_v3((float *)&varray[elementsize*curface*3],(float *)attribs.orco.array[mface->v3]);
|
|
|
|
|
copy_v3_v3((float *)&varray[elementsize*curface*3+elementsize],(float *)attribs.orco.array[mface->v4]);
|
|
|
|
|
copy_v3_v3((float *)&varray[elementsize*curface*3+elementsize*2],(float *)attribs.orco.array[mface->v1]);
|
2009-10-23 01:22:05 +02:00
|
|
|
offset += sizeof(float)*3;
|
|
|
|
|
}
|
|
|
|
|
for(b = 0; b < attribs.tottface; b++) {
|
|
|
|
|
MTFace *tf = &attribs.tface[b].array[a];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v2_v2((float *)&varray[elementsize*curface*3+offset],tf->uv[2]);
|
|
|
|
|
copy_v2_v2((float *)&varray[elementsize*curface*3+offset+elementsize],tf->uv[3]);
|
|
|
|
|
copy_v2_v2((float *)&varray[elementsize*curface*3+offset+elementsize*2],tf->uv[0]);
|
2009-10-23 01:22:05 +02:00
|
|
|
offset += sizeof(float)*2;
|
|
|
|
|
}
|
|
|
|
|
for(b = 0; b < attribs.totmcol; b++) {
|
|
|
|
|
MCol *cp = &attribs.mcol[b].array[a*4 + 2];
|
|
|
|
|
GLubyte col[4];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4_char((char *)&varray[elementsize*curface*3+offset], (char *)col);
|
2009-10-23 01:22:05 +02:00
|
|
|
cp = &attribs.mcol[b].array[a*4 + 3];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4_char((char *)&varray[elementsize*curface*3+offset+elementsize], (char *)col);
|
2009-10-23 01:22:05 +02:00
|
|
|
cp = &attribs.mcol[b].array[a*4 + 0];
|
|
|
|
|
col[0]= cp->b; col[1]= cp->g; col[2]= cp->r; col[3]= cp->a;
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4_char((char *)&varray[elementsize*curface*3+offset+elementsize*2], (char *)col);
|
2009-10-23 01:22:05 +02:00
|
|
|
offset += sizeof(unsigned char)*4;
|
|
|
|
|
}
|
|
|
|
|
if(attribs.tottang) {
|
|
|
|
|
float *tang = attribs.tang.array[a*4 + 2];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4((float *)&varray[elementsize*curface*3+offset], tang);
|
2009-10-23 01:22:05 +02:00
|
|
|
tang = attribs.tang.array[a*4 + 3];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4((float *)&varray[elementsize*curface*3+offset+elementsize], tang);
|
2009-10-23 01:22:05 +02:00
|
|
|
tang = attribs.tang.array[a*4 + 0];
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v4_v4((float *)&varray[elementsize*curface*3+offset+elementsize*2], tang);
|
2011-02-14 19:18:46 +01:00
|
|
|
offset += sizeof(float)*4;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
2011-07-27 15:03:56 +02:00
|
|
|
(void)offset;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
curface++;
|
2010-02-15 13:35:32 +01:00
|
|
|
i++;
|
2009-10-23 01:22:05 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
numfaces = curface - start;
|
|
|
|
|
if( numfaces > 0 ) {
|
|
|
|
|
if( dodraw ) {
|
|
|
|
|
if( numdata != 0 ) {
|
|
|
|
|
GPU_buffer_unlock(buffer);
|
|
|
|
|
GPU_interleaved_attrib_setup(buffer,datatypes,numdata);
|
|
|
|
|
}
|
|
|
|
|
glDrawArrays(GL_TRIANGLES,start*3,(curface-start)*3);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
GPU_buffer_unbind();
|
|
|
|
|
}
|
== GPU Buffers ==
This patch attempts to clean up and document the GPU buffers
code. There are a few bug fixes as well.
Patch reviewed here: http://codereview.appspot.com/4631052/
Summary:
* Bugfix: make GPU_buffer_copy_normal convert from shorts to floats
correctly, also fixed the use of cached face normal CustomData.
* Bugfix: changed the `mat_nr' field of GPUBufferMaterial from char to
short.
* Changed color buffer setup to not alloc a temporary copy of color
data, just passes the MCol data in directly.
* Changed the GPU buffer pool code to make clearer what operates
specifically on the global pool.
* Lots of refactoring for GPU_drawobject_new; should operate mostly
the same (except got rid of one unecessary allocation), just split
into more functions and without macros now.
* Converted some #defines into enumerations.
* Made some stuff private, pulled out of header file.
* Deleted unused function GPU_buffer_pool_free_unused().
* Removed GPU_interleaved_setup and related #defines. (I think this
was used for editmode VBOs, but those were disabled.)
* Added lots of comments.
* Added a few comments in the code signed `--nicholas' to note places
where I am unsure about design or usage, would be good to address
these better.
* Code formatting changed to be more consistent with the rest of
Blender.
* Renamed some fields and variables to be more consistent with
Blender's naming conventions.
* Renamed some fields and variables to use more descriptive names,
e.g. renamed `redir' to `mat_orig_to_new'.
* Removed print outs with DEBUG_VBO -- don't feel too strongly about
this one, just not used elsewhere in Blender, could be easily added
back if others disagree though.
* Moved the PBVH drawing code down to the bottom of the file, before
was sitting in the middle of the other VBO code
2011-07-08 21:58:02 +02:00
|
|
|
GPU_buffer_free(buffer);
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
glShadeModel(GL_FLAT);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-07 05:41:14 +01:00
|
|
|
static void cdDM_drawFacesGLSL(DerivedMesh *dm, DMSetMaterial setMaterial)
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
{
|
|
|
|
|
dm->drawMappedFacesGLSL(dm, setMaterial, NULL, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-08 14:07:16 +01:00
|
|
|
static void cdDM_drawMappedFacesMat(DerivedMesh *dm,
|
|
|
|
|
void (*setMaterial)(void *userData, int, void *attribs),
|
|
|
|
|
int (*setFace)(void *userData, int index), void *userData)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
GPUVertexAttribs gattribs;
|
|
|
|
|
DMVertexAttribs attribs;
|
|
|
|
|
MVert *mvert = cddm->mvert;
|
|
|
|
|
MFace *mf = cddm->mface;
|
2011-11-10 04:40:02 +01:00
|
|
|
float (*nors)[3] = dm->getTessFaceDataArray(dm, CD_NORMAL);
|
2011-11-08 14:07:16 +01:00
|
|
|
int a, matnr, new_matnr;
|
2011-11-23 21:44:04 +01:00
|
|
|
int orig, *index = dm->getTessFaceDataArray(dm, CD_ORIGINDEX);
|
2011-11-08 14:07:16 +01:00
|
|
|
|
|
|
|
|
cdDM_update_normals_from_pbvh(dm);
|
|
|
|
|
|
|
|
|
|
matnr = -1;
|
|
|
|
|
|
|
|
|
|
glShadeModel(GL_SMOOTH);
|
|
|
|
|
|
|
|
|
|
memset(&attribs, 0, sizeof(attribs));
|
|
|
|
|
|
|
|
|
|
glBegin(GL_QUADS);
|
|
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
for(a = 0; a < dm->numTessFaceData; a++, mf++) {
|
2011-11-08 14:07:16 +01:00
|
|
|
const int smoothnormal = (mf->flag & ME_SMOOTH);
|
|
|
|
|
|
|
|
|
|
/* material */
|
|
|
|
|
new_matnr = mf->mat_nr + 1;
|
|
|
|
|
|
|
|
|
|
if(new_matnr != matnr) {
|
|
|
|
|
glEnd();
|
|
|
|
|
|
|
|
|
|
setMaterial(userData, matnr = new_matnr, &gattribs);
|
|
|
|
|
DM_vertex_attributes_from_gpu(dm, &gattribs, &attribs);
|
|
|
|
|
|
|
|
|
|
glBegin(GL_QUADS);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* skipping faces */
|
|
|
|
|
if(setFace) {
|
|
|
|
|
orig = (index)? index[a]: a;
|
|
|
|
|
|
|
|
|
|
if(orig != ORIGINDEX_NONE && !setFace(userData, orig))
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* smooth normal */
|
|
|
|
|
if(!smoothnormal) {
|
|
|
|
|
if(nors) {
|
|
|
|
|
glNormal3fv(nors[a]);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
/* TODO ideally a normal layer should always be available */
|
|
|
|
|
float nor[3];
|
|
|
|
|
|
|
|
|
|
if(mf->v4)
|
|
|
|
|
normal_quad_v3( nor,mvert[mf->v1].co, mvert[mf->v2].co, mvert[mf->v3].co, mvert[mf->v4].co);
|
|
|
|
|
else
|
|
|
|
|
normal_tri_v3( nor,mvert[mf->v1].co, mvert[mf->v2].co, mvert[mf->v3].co);
|
|
|
|
|
|
|
|
|
|
glNormal3fv(nor);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* vertices */
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mf->v1, 0, smoothnormal);
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mf->v2, 1, smoothnormal);
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mf->v3, 2, smoothnormal);
|
|
|
|
|
|
|
|
|
|
if(mf->v4)
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mf->v4, 3, smoothnormal);
|
|
|
|
|
else
|
|
|
|
|
cddm_draw_attrib_vertex(&attribs, mvert, a, mf->v3, 2, smoothnormal);
|
|
|
|
|
}
|
|
|
|
|
glEnd();
|
|
|
|
|
|
|
|
|
|
glShadeModel(GL_FLAT);
|
|
|
|
|
}
|
|
|
|
|
|
2012-03-07 05:41:14 +01:00
|
|
|
static void cdDM_drawMappedEdges(DerivedMesh *dm, DMSetDrawOptions setDrawOptions, void *userData)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *vert = cddm->mvert;
|
|
|
|
|
MEdge *edge = cddm->medge;
|
|
|
|
|
int i, orig, *index = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
glBegin(GL_LINES);
|
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 05:28:02 +01:00
|
|
|
for(i = 0; i < dm->numEdgeData; i++, edge++) {
|
|
|
|
|
if(index) {
|
|
|
|
|
orig = *index++;
|
|
|
|
|
if(setDrawOptions && orig == ORIGINDEX_NONE) continue;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
orig = i;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2012-03-08 07:47:05 +01:00
|
|
|
if(!setDrawOptions || (setDrawOptions(userData, orig) != DM_DRAW_OPTION_SKIP)) {
|
2006-08-28 03:12:36 +02:00
|
|
|
glVertex3fv(vert[edge->v1].co);
|
|
|
|
|
glVertex3fv(vert[edge->v2].co);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
glEnd();
|
|
|
|
|
}
|
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
static void cdDM_foreachMappedVert(
|
2010-03-22 10:30:00 +01:00
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int index, float *co,
|
|
|
|
|
float *no_f, short *no_s),
|
|
|
|
|
void *userData)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
MVert *mv = CDDM_get_verts(dm);
|
|
|
|
|
int i, orig, *index = DM_get_vert_data_layer(dm, CD_ORIGINDEX);
|
|
|
|
|
|
|
|
|
|
for(i = 0; i < dm->numVertData; i++, mv++) {
|
|
|
|
|
if(index) {
|
|
|
|
|
orig = *index++;
|
|
|
|
|
if(orig == ORIGINDEX_NONE) continue;
|
|
|
|
|
func(userData, orig, mv->co, NULL, mv->no);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
func(userData, i, mv->co, NULL, mv->no);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_foreachMappedEdge(
|
2010-03-22 10:30:00 +01:00
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int index,
|
|
|
|
|
float *v0co, float *v1co),
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*) dm;
|
|
|
|
|
MVert *mv = cddm->mvert;
|
|
|
|
|
MEdge *med = cddm->medge;
|
|
|
|
|
int i, orig, *index = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
|
|
|
|
|
|
|
|
|
|
for(i = 0; i < dm->numEdgeData; i++, med++) {
|
|
|
|
|
if (index) {
|
|
|
|
|
orig = *index++;
|
|
|
|
|
if(orig == ORIGINDEX_NONE) continue;
|
|
|
|
|
func(userData, orig, mv[med->v1].co, mv[med->v2].co);
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
func(userData, i, mv[med->v1].co, mv[med->v2].co);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void cdDM_foreachMappedFaceCenter(
|
2010-03-22 10:30:00 +01:00
|
|
|
DerivedMesh *dm,
|
|
|
|
|
void (*func)(void *userData, int index,
|
|
|
|
|
float *cent, float *no),
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
MVert *mv = cddm->mvert;
|
(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 12:06:25 +02:00
|
|
|
MPoly *mf = cddm->mpoly;
|
|
|
|
|
MLoop *ml = cddm->mloop;
|
2009-06-16 22:08:40 +02:00
|
|
|
int i, j, 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 05:28:02 +01:00
|
|
|
|
2009-06-16 22:08:40 +02:00
|
|
|
index = CustomData_get_layer(&dm->polyData, CD_ORIGINDEX);
|
|
|
|
|
mf = cddm->mpoly;
|
(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 12:06:25 +02:00
|
|
|
for(i = 0; i < dm->numPolyData; i++, mf++) {
|
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 05:28:02 +01:00
|
|
|
float cent[3];
|
|
|
|
|
float no[3];
|
|
|
|
|
|
|
|
|
|
if (index) {
|
|
|
|
|
orig = *index++;
|
|
|
|
|
if(orig == ORIGINDEX_NONE) continue;
|
|
|
|
|
}
|
|
|
|
|
else
|
|
|
|
|
orig = 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 12:06:25 +02:00
|
|
|
|
|
|
|
|
ml = &cddm->mloop[mf->loopstart];
|
|
|
|
|
cent[0] = cent[1] = cent[2] = 0.0f;
|
|
|
|
|
for (j=0; j<mf->totloop; j++, ml++) {
|
2009-11-23 15:41:22 +01:00
|
|
|
add_v3_v3v3(cent, cent, mv[ml->v].co);
|
(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 12:06:25 +02:00
|
|
|
}
|
2009-11-23 15:41:22 +01:00
|
|
|
mul_v3_fl(cent, 1.0f / (float)j);
|
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 05:28:02 +01: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 12:06:25 +02:00
|
|
|
ml = &cddm->mloop[mf->loopstart];
|
|
|
|
|
if (j > 3) {
|
2009-11-23 15:41:22 +01:00
|
|
|
normal_quad_v3(no, mv[ml->v].co, mv[(ml+1)->v].co,
|
|
|
|
|
mv[(ml+2)->v].co, mv[(ml+3)->v].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 05:28:02 +01:00
|
|
|
} else {
|
2011-09-24 13:03:52 +02:00
|
|
|
normal_tri_v3(no, mv[ml->v].co, mv[(ml+1)->v].co, mv[(ml+2)->v].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 05:28:02 +01:00
|
|
|
}
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
func(userData, orig, cent, no);
|
|
|
|
|
}
|
2009-06-16 22:08:40 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2012-03-02 17:05:54 +01:00
|
|
|
void CDDM_recalc_tessellation_ex(DerivedMesh *dm, const int do_face_nor_cpy)
|
2009-08-28 11:36:31 +02:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
|
2012-03-02 17:05:54 +01:00
|
|
|
dm->numTessFaceData = mesh_recalcTessellation(&dm->faceData, &dm->loopData, &dm->polyData,
|
2012-01-19 18:51:52 +01:00
|
|
|
cddm->mvert,
|
|
|
|
|
dm->numTessFaceData, dm->numLoopData, dm->numPolyData,
|
2012-01-19 20:23:25 +01:00
|
|
|
do_face_nor_cpy);
|
2011-11-23 21:44:04 +01:00
|
|
|
|
|
|
|
|
if (!CustomData_get_layer(&dm->faceData, CD_ORIGINDEX)) {
|
|
|
|
|
int *polyIndex = CustomData_get_layer(&dm->faceData, CD_POLYINDEX);
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_REFERENCE, polyIndex, dm->numTessFaceData);
|
2011-11-23 21:44:04 +01:00
|
|
|
}
|
|
|
|
|
|
2009-11-03 06:06:04 +01:00
|
|
|
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
|
2011-12-01 10:49:27 +01:00
|
|
|
|
2012-03-02 17:05:54 +01:00
|
|
|
/* Tessellation recreated faceData, and the active layer indices need to get re-propagated
|
2012-03-09 19:28:30 +01:00
|
|
|
* from loops and polys to faces */
|
2011-12-01 10:49:27 +01:00
|
|
|
CustomData_bmesh_update_active_layers(&dm->faceData, &dm->polyData, &dm->loopData);
|
2009-11-03 06:06:04 +01:00
|
|
|
}
|
|
|
|
|
|
2012-03-02 17:05:54 +01:00
|
|
|
void CDDM_recalc_tessellation(DerivedMesh *dm)
|
2012-01-19 20:23:25 +01:00
|
|
|
{
|
2012-03-02 17:05:54 +01:00
|
|
|
CDDM_recalc_tessellation_ex(dm, TRUE);
|
2012-01-19 20:23:25 +01:00
|
|
|
}
|
|
|
|
|
|
2009-10-28 07:06:05 +01:00
|
|
|
static void cdDM_free_internal(CDDerivedMesh *cddm)
|
|
|
|
|
{
|
2012-02-05 07:20:51 +01:00
|
|
|
if(cddm->pmap) MEM_freeN(cddm->pmap);
|
|
|
|
|
if(cddm->pmap_mem) MEM_freeN(cddm->pmap_mem);
|
2009-10-28 07:06: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 05:28:02 +01:00
|
|
|
static void cdDM_release(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
|
2009-10-28 07:06:05 +01: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 05:28:02 +01:00
|
|
|
MEM_freeN(cddm);
|
2009-10-28 07:06: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 05:28:02 +01:00
|
|
|
}
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-09-06 08:47:59 +02:00
|
|
|
int CDDM_Check(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
return dm && dm->getMinMax == cdDM_getMinMax;
|
|
|
|
|
}
|
|
|
|
|
|
2006-08-28 03:12:36 +02: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 05:28:02 +01:00
|
|
|
static CDDerivedMesh *cdDM_create(const char *desc)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm;
|
2006-08-28 03:12:36 +02: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 05:28:02 +01:00
|
|
|
cddm = MEM_callocN(sizeof(*cddm), desc);
|
|
|
|
|
dm = &cddm->dm;
|
2006-08-28 03:12:36 +02: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 12:06:25 +02:00
|
|
|
dm->getNumTessFaces = cdDM_getNumTessFaces;
|
2011-11-30 19:03:56 +01:00
|
|
|
dm->getNumLoops = cdDM_getNumLoops;
|
2011-11-29 14:01:51 +01: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 12:06:25 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
dm->getVert = cdDM_getVert;
|
|
|
|
|
dm->getEdge = cdDM_getEdge;
|
2011-11-29 14:01:51 +01: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 05:28:02 +01:00
|
|
|
dm->copyVertArray = cdDM_copyVertArray;
|
|
|
|
|
dm->copyEdgeArray = cdDM_copyEdgeArray;
|
2011-11-29 14:01:51 +01:00
|
|
|
dm->copyTessFaceArray = cdDM_copyTessFaceArray;
|
2011-06-14 05:16:08 +02:00
|
|
|
dm->copyLoopArray = cdDM_copyLoopArray;
|
|
|
|
|
dm->copyPolyArray = cdDM_copyPolyArray;
|
2011-11-13 16:13:59 +01:00
|
|
|
|
2011-11-29 14:01:51 +01: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;
|
|
|
|
|
|
2012-02-06 07:56:54 +01:00
|
|
|
dm->calcNormals = CDDM_calc_normals_mapping;
|
2012-03-02 17:05:54 +01:00
|
|
|
dm->recalcTessellation = CDDM_recalc_tessellation;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
dm->getVertCos = cdDM_getVertCos;
|
|
|
|
|
dm->getVertCo = cdDM_getVertCo;
|
|
|
|
|
dm->getVertNo = cdDM_getVertNo;
|
|
|
|
|
|
2009-10-28 07:06:05 +01:00
|
|
|
dm->getPBVH = cdDM_getPBVH;
|
2012-02-05 07:20:51 +01:00
|
|
|
dm->getPolyMap = cdDM_getPolyMap;
|
2009-10-28 07:06:05 +01:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
dm->drawVerts = cdDM_drawVerts;
|
|
|
|
|
|
|
|
|
|
dm->drawUVEdges = cdDM_drawUVEdges;
|
|
|
|
|
dm->drawEdges = cdDM_drawEdges;
|
|
|
|
|
dm->drawLooseEdges = cdDM_drawLooseEdges;
|
|
|
|
|
dm->drawMappedEdges = cdDM_drawMappedEdges;
|
|
|
|
|
|
|
|
|
|
dm->drawFacesSolid = cdDM_drawFacesSolid;
|
|
|
|
|
dm->drawFacesTex = cdDM_drawFacesTex;
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
dm->drawFacesGLSL = cdDM_drawFacesGLSL;
|
2006-08-28 03:12:36 +02:00
|
|
|
dm->drawMappedFaces = cdDM_drawMappedFaces;
|
|
|
|
|
dm->drawMappedFacesTex = cdDM_drawMappedFacesTex;
|
Merge of first part of changes from the apricot branch, especially
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
2008-09-04 22:51:28 +02:00
|
|
|
dm->drawMappedFacesGLSL = cdDM_drawMappedFacesGLSL;
|
2011-11-08 14:07:16 +01:00
|
|
|
dm->drawMappedFacesMat = cdDM_drawMappedFacesMat;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
dm->foreachMappedVert = cdDM_foreachMappedVert;
|
|
|
|
|
dm->foreachMappedEdge = cdDM_foreachMappedEdge;
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
return cddm;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
DerivedMesh *CDDM_new(int numVerts, int numEdges, int numTessFaces, int numLoops, int numPolys)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_new dm");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
DM_init(dm, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces, numLoops, numPolys);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2008-06-09 19:22:38 +02: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 19:03:56 +01:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
|
|
|
|
|
CustomData_add_layer(&dm->faceData, CD_POLYINDEX, 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 12:06:25 +02:00
|
|
|
CustomData_add_layer(&dm->polyData, CD_ORIGINDEX, CD_CALLOC, NULL, numPolys);
|
2008-06-09 19:22:38 +02:00
|
|
|
|
2006-12-12 22:29:09 +01: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 19:03:56 +01: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 12:06:25 +02: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 22:29:09 +01: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 12:06:25 +02:00
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
return dm;
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-16 16:32:17 +02:00
|
|
|
DerivedMesh *CDDM_from_mesh(Mesh *mesh, Object *UNUSED(ob))
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_from_mesh dm");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
2009-01-06 19:59:03 +01:00
|
|
|
CustomDataMask mask = CD_MASK_MESH & (~CD_MASK_MDISPS);
|
2009-11-04 21:23:48 +01:00
|
|
|
int alloctype;
|
2011-11-13 16:13:59 +01:00
|
|
|
int *polyindex = NULL;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2009-11-04 21:23:48 +01:00
|
|
|
/* this does a referenced copy, with an exception for fluidsim */
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2010-01-13 08:26:11 +01:00
|
|
|
DM_init(dm, DM_TYPE_CDDM, mesh->totvert, mesh->totedge, mesh->totface,
|
(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 12:06:25 +02:00
|
|
|
mesh->totloop, mesh->totpoly);
|
2008-06-09 19:22:38 +02:00
|
|
|
|
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 23:09:57 +01:00
|
|
|
dm->deformedOnly = 1;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2008-07-25 20:57:16 +02:00
|
|
|
alloctype= CD_REFERENCE;
|
2008-02-21 14:15:21 +01:00
|
|
|
|
2009-01-06 19:59:03 +01:00
|
|
|
CustomData_merge(&mesh->vdata, &dm->vertData, mask, alloctype,
|
2010-03-22 10:30:00 +01:00
|
|
|
mesh->totvert);
|
2009-01-06 19:59:03 +01:00
|
|
|
CustomData_merge(&mesh->edata, &dm->edgeData, mask, alloctype,
|
2010-03-22 10:30:00 +01:00
|
|
|
mesh->totedge);
|
2011-11-13 16:13:59 +01:00
|
|
|
CustomData_merge(&mesh->fdata, &dm->faceData, mask|CD_MASK_POLYINDEX, alloctype,
|
2010-03-22 10:30:00 +01:00
|
|
|
mesh->totface);
|
(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 12:06:25 +02:00
|
|
|
CustomData_merge(&mesh->ldata, &dm->loopData, mask, alloctype,
|
|
|
|
|
mesh->totloop);
|
|
|
|
|
CustomData_merge(&mesh->pdata, &dm->polyData, mask, alloctype,
|
|
|
|
|
mesh->totpoly);
|
2006-08-28 03:12:36 +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 05:28:02 +01: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 12:06:25 +02:00
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
2009-09-05 08:10:30 +02:00
|
|
|
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2011-11-23 17:39:07 +01:00
|
|
|
/* commented since even when CD_POLYINDEX was first added this line fails
|
|
|
|
|
* on the default cube, (after editmode toggle too) - campbell */
|
|
|
|
|
#if 0
|
2011-11-13 16:13:59 +01:00
|
|
|
BLI_assert(CustomData_has_layer(&cddm->dm.faceData, CD_POLYINDEX));
|
2011-11-23 17:39:07 +01:00
|
|
|
#endif
|
2011-11-13 16:13:59 +01:00
|
|
|
|
|
|
|
|
polyindex = CustomData_get_layer(&dm->faceData, CD_POLYINDEX);
|
|
|
|
|
if (!CustomData_has_layer(&cddm->dm.faceData, CD_ORIGINDEX)) {
|
|
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_REFERENCE, polyindex, mesh->totface);
|
|
|
|
|
}
|
2009-08-28 11:36:31 +02:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
return dm;
|
|
|
|
|
}
|
|
|
|
|
|
2010-03-05 17:47:52 +01:00
|
|
|
DerivedMesh *CDDM_from_curve(Object *ob)
|
2010-03-08 14:49:13 +01:00
|
|
|
{
|
2011-01-05 11:40:38 +01:00
|
|
|
return CDDM_from_curve_customDB(ob, &ob->disp);
|
2010-03-08 14:49:13 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DerivedMesh *CDDM_from_curve_customDB(Object *ob, ListBase *dispbase)
|
2010-03-05 17:47:52 +01:00
|
|
|
{
|
|
|
|
|
DerivedMesh *dm;
|
|
|
|
|
CDDerivedMesh *cddm;
|
|
|
|
|
MVert *allvert;
|
|
|
|
|
MEdge *alledge;
|
2011-04-15 03:19:13 +02:00
|
|
|
MLoop *allloop;
|
|
|
|
|
MPoly *allpoly;
|
2012-02-03 05:58:55 +01:00
|
|
|
int totvert, totedge, totloop, totpoly;
|
2010-03-05 17:47:52 +01:00
|
|
|
|
2010-03-08 14:49:13 +01:00
|
|
|
if (nurbs_to_mdata_customdb(ob, dispbase, &allvert, &totvert, &alledge,
|
2012-02-03 05:58:55 +01:00
|
|
|
&totedge, &allloop, &allpoly, &totloop, &totpoly) != 0) {
|
2010-03-05 17:47:52 +01:00
|
|
|
/* Error initializing mdata. This often happens when curve is empty */
|
2010-07-19 06:44:37 +02:00
|
|
|
return CDDM_new(0, 0, 0, 0, 0);
|
2010-03-05 17:47:52 +01:00
|
|
|
}
|
|
|
|
|
|
2012-02-03 05:58:55 +01:00
|
|
|
dm = CDDM_new(totvert, totedge, 0, totloop, totpoly);
|
2010-03-05 17:47:52 +01:00
|
|
|
dm->deformedOnly = 1;
|
|
|
|
|
|
|
|
|
|
cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
|
|
|
|
|
memcpy(cddm->mvert, allvert, totvert*sizeof(MVert));
|
|
|
|
|
memcpy(cddm->medge, alledge, totedge*sizeof(MEdge));
|
2011-04-15 03:19:13 +02:00
|
|
|
memcpy(cddm->mloop, allloop, totloop*sizeof(MLoop));
|
|
|
|
|
memcpy(cddm->mpoly, allpoly, totpoly*sizeof(MPoly));
|
2010-03-05 17:47:52 +01:00
|
|
|
|
|
|
|
|
MEM_freeN(allvert);
|
|
|
|
|
MEM_freeN(alledge);
|
2011-04-15 03:19:13 +02:00
|
|
|
MEM_freeN(allloop);
|
|
|
|
|
MEM_freeN(allpoly);
|
2010-03-05 17:47:52 +01:00
|
|
|
|
2012-02-03 05:58:55 +01:00
|
|
|
CDDM_calc_edges(dm);
|
|
|
|
|
|
2010-03-05 17:47:52 +01:00
|
|
|
return dm;
|
|
|
|
|
}
|
2009-05-16 18:18:08 +02:00
|
|
|
|
|
|
|
|
static void loops_to_customdata_corners(BMesh *bm, CustomData *facedata,
|
2010-07-19 06:44:37 +02:00
|
|
|
int cdindex, BMLoop *l3[3],
|
|
|
|
|
int numCol, int numTex)
|
2009-05-16 18:18:08 +02:00
|
|
|
{
|
|
|
|
|
BMLoop *l;
|
|
|
|
|
BMFace *f = l3[0]->f;
|
|
|
|
|
MTFace *texface;
|
|
|
|
|
MTexPoly *texpoly;
|
|
|
|
|
MCol *mcol;
|
|
|
|
|
MLoopCol *mloopcol;
|
|
|
|
|
MLoopUV *mloopuv;
|
2012-03-22 09:41:50 +01:00
|
|
|
int i, j, hasPCol = CustomData_has_layer(&bm->ldata, CD_PREVIEW_MLOOPCOL);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-02-23 03:17:50 +01:00
|
|
|
for (i=0; i < numTex; i++) {
|
2009-05-16 18:18:08 +02:00
|
|
|
texface = CustomData_get_n(facedata, CD_MTFACE, cdindex, i);
|
2009-06-23 07:35:49 +02:00
|
|
|
texpoly = CustomData_bmesh_get_n(&bm->pdata, f->head.data, CD_MTEXPOLY, i);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-02-08 10:02:10 +01:00
|
|
|
ME_MTEXFACE_CPY(texface, texpoly);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2009-07-22 02:51:13 +02:00
|
|
|
for (j=0; j<3; j++) {
|
2009-05-16 18:18:08 +02:00
|
|
|
l = l3[j];
|
2009-06-23 07:35:49 +02:00
|
|
|
mloopuv = CustomData_bmesh_get_n(&bm->ldata, l->head.data, CD_MLOOPUV, i);
|
2012-02-05 14:25:42 +01:00
|
|
|
copy_v2_v2(texface->uv[j], mloopuv->uv);
|
2009-05-16 18:18:08 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2012-02-23 03:17:50 +01:00
|
|
|
for (i=0; i < numCol; i++) {
|
2009-05-16 18:18:08 +02:00
|
|
|
mcol = CustomData_get_n(facedata, CD_MCOL, cdindex, i);
|
|
|
|
|
|
|
|
|
|
for (j=0; j<3; j++) {
|
|
|
|
|
l = l3[j];
|
2009-06-23 07:35:49 +02:00
|
|
|
mloopcol = CustomData_bmesh_get_n(&bm->ldata, l->head.data, CD_MLOOPCOL, i);
|
2012-03-17 21:39:28 +01:00
|
|
|
MESH_MLOOPCOL_TO_MCOL(mloopcol, &mcol[j]);
|
2009-05-16 18:18:08 +02:00
|
|
|
}
|
|
|
|
|
}
|
2009-08-31 17:57:13 +02:00
|
|
|
|
2012-03-22 09:41:50 +01:00
|
|
|
if (hasPCol) {
|
|
|
|
|
mcol = CustomData_get(facedata, cdindex, CD_PREVIEW_MCOL);
|
2009-08-31 17:57:13 +02:00
|
|
|
|
|
|
|
|
for (j=0; j<3; j++) {
|
|
|
|
|
l = l3[j];
|
2012-03-22 09:41:50 +01:00
|
|
|
mloopcol = CustomData_bmesh_get(&bm->ldata, l->head.data, CD_PREVIEW_MLOOPCOL);
|
2012-03-17 21:39:28 +01:00
|
|
|
MESH_MLOOPCOL_TO_MCOL(mloopcol, &mcol[j]);
|
2009-08-31 17:57:13 +02:00
|
|
|
}
|
|
|
|
|
}
|
2009-05-16 18:18:08 +02:00
|
|
|
}
|
|
|
|
|
|
2012-01-18 16:09:27 +01:00
|
|
|
DerivedMesh *CDDM_from_BMEditMesh(BMEditMesh *em, Mesh *UNUSED(me), int use_mdisps, int use_tessface)
|
2009-05-16 18:18:08 +02:00
|
|
|
{
|
|
|
|
|
BMesh *bm = em->bm;
|
2012-02-07 04:03:09 +01:00
|
|
|
|
|
|
|
|
DerivedMesh *dm = CDDM_new(bm->totvert,
|
|
|
|
|
bm->totedge,
|
|
|
|
|
use_tessface ? em->tottri : 0,
|
|
|
|
|
bm->totloop,
|
|
|
|
|
bm->totface);
|
|
|
|
|
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)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 12:06:25 +02:00
|
|
|
BMIter iter, liter;
|
2009-05-16 18:18:08 +02: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 12:06:25 +02:00
|
|
|
MLoop *mloop = cddm->mloop;
|
|
|
|
|
MPoly *mpoly = cddm->mpoly;
|
2012-01-18 15:52:47 +01:00
|
|
|
int numCol = CustomData_number_of_layers(&bm->ldata, CD_MLOOPCOL);
|
|
|
|
|
int numTex = CustomData_number_of_layers(&bm->pdata, CD_MTEXPOLY);
|
2012-01-18 16:09:27 +01:00
|
|
|
int *index, add_orig;
|
2011-03-27 05:29:27 +02:00
|
|
|
int has_crease, has_edge_bweight, has_vert_bweight;
|
2012-01-18 15:52:47 +01:00
|
|
|
CustomDataMask mask;
|
2011-12-28 05:43:29 +01:00
|
|
|
unsigned int i, j;
|
2011-03-27 05:29:27 +02:00
|
|
|
|
2012-01-18 15:52:47 +01:00
|
|
|
has_edge_bweight = CustomData_has_layer(&bm->edata, CD_BWEIGHT);
|
|
|
|
|
has_vert_bweight = CustomData_has_layer(&bm->vdata, CD_BWEIGHT);
|
|
|
|
|
has_crease = CustomData_has_layer(&bm->edata, CD_CREASE);
|
2011-03-27 05:29:27 +02:00
|
|
|
|
2009-05-16 18:18:08 +02:00
|
|
|
dm->deformedOnly = 1;
|
2009-06-23 07:35:49 +02:00
|
|
|
|
|
|
|
|
/*don't add origindex layer if one already exists*/
|
2012-01-18 15:52:47 +01:00
|
|
|
add_orig = !CustomData_has_layer(&bm->pdata, CD_ORIGINDEX);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-01-18 15:52:47 +01:00
|
|
|
mask = use_mdisps ? CD_MASK_DERIVEDMESH|CD_MASK_MDISPS : CD_MASK_DERIVEDMESH;
|
2011-04-15 07:20:18 +02:00
|
|
|
|
2012-03-09 19:28:30 +01:00
|
|
|
/* don't process shapekeys, we only feed them through the modifier stack as needed,
|
|
|
|
|
* e.g. for applying modifiers or the like*/
|
2012-01-18 15:52:47 +01:00
|
|
|
mask &= ~CD_MASK_SHAPEKEY;
|
|
|
|
|
CustomData_merge(&bm->vdata, &dm->vertData, mask,
|
2009-05-16 18:18:08 +02:00
|
|
|
CD_CALLOC, dm->numVertData);
|
2012-01-18 15:52:47 +01:00
|
|
|
CustomData_merge(&bm->edata, &dm->edgeData, mask,
|
2009-06-23 07:35:49 +02:00
|
|
|
CD_CALLOC, dm->numEdgeData);
|
2012-01-18 15:52:47 +01:00
|
|
|
CustomData_merge(&bm->ldata, &dm->loopData, mask,
|
(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 12:06:25 +02:00
|
|
|
CD_CALLOC, dm->numLoopData);
|
2012-01-18 15:52:47 +01:00
|
|
|
CustomData_merge(&bm->pdata, &dm->polyData, mask,
|
(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 12:06:25 +02:00
|
|
|
CD_CALLOC, dm->numPolyData);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-03-02 17:05:54 +01:00
|
|
|
/*add tessellation mface layers*/
|
2012-01-18 16:09:27 +01:00
|
|
|
if (use_tessface) {
|
|
|
|
|
CustomData_from_bmeshpoly(&dm->faceData, &dm->polyData, &dm->loopData, em->tottri);
|
|
|
|
|
}
|
2009-05-16 18:18:08 +02:00
|
|
|
|
|
|
|
|
index = dm->getVertDataArray(dm, CD_ORIGINDEX);
|
|
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
eve = BM_iter_new(&iter, bm, BM_VERTS_OF_MESH, NULL);
|
|
|
|
|
for (i=0; eve; eve=BM_iter_step(&iter), i++, index++) {
|
2009-05-16 18:18:08 +02:00
|
|
|
MVert *mv = &mvert[i];
|
|
|
|
|
|
2011-11-07 10:02:10 +01:00
|
|
|
copy_v3_v3(mv->co, eve->co);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
BM_elem_index_set(eve, i); /* set_inline */
|
2009-06-23 07:35:49 +02:00
|
|
|
|
2011-10-27 14:17:02 +02:00
|
|
|
normal_float_to_short_v3(mv->no, eve->no);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
mv->flag = BM_vert_flag_to_mflag(eve);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2011-03-27 05:29:27 +02:00
|
|
|
if (has_vert_bweight)
|
2012-02-12 11:51:45 +01:00
|
|
|
mv->bweight = (unsigned char)(BM_elem_float_data_get(&bm->vdata, eve, CD_BWEIGHT)*255.0f);
|
2011-03-27 05:29:27 +02:00
|
|
|
|
2009-06-23 07:35:49 +02:00
|
|
|
if (add_orig) *index = i;
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2009-06-23 07:35:49 +02:00
|
|
|
CustomData_from_bmesh_block(&bm->vdata, &dm->vertData, eve->head.data, i);
|
2009-05-16 18:18:08 +02:00
|
|
|
}
|
2011-11-16 13:38:40 +01:00
|
|
|
bm->elem_index_dirty &= ~BM_VERT;
|
2009-05-16 18:18:08 +02:00
|
|
|
|
|
|
|
|
index = dm->getEdgeDataArray(dm, CD_ORIGINDEX);
|
2012-02-12 11:51:45 +01:00
|
|
|
eed = BM_iter_new(&iter, bm, BM_EDGES_OF_MESH, NULL);
|
|
|
|
|
for (i=0; eed; eed=BM_iter_step(&iter), i++, index++) {
|
2009-05-16 18:18:08 +02:00
|
|
|
MEdge *med = &medge[i];
|
|
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
BM_elem_index_set(eed, i); /* set_inline */
|
2009-06-23 07:35:49 +02:00
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
med->v1 = BM_elem_index_get(eed->v1);
|
|
|
|
|
med->v2 = BM_elem_index_get(eed->v2);
|
2011-03-27 05:29:27 +02:00
|
|
|
|
|
|
|
|
if (has_crease)
|
2012-02-12 11:51:45 +01:00
|
|
|
med->crease = (unsigned char)(BM_elem_float_data_get(&bm->edata, eed, CD_CREASE)*255.0f);
|
2011-03-27 05:29:27 +02:00
|
|
|
if (has_edge_bweight)
|
2012-02-12 11:51:45 +01:00
|
|
|
med->bweight = (unsigned char)(BM_elem_float_data_get(&bm->edata, eed, CD_BWEIGHT)*255.0f);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
med->flag = BM_edge_flag_to_mflag(eed);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2009-06-23 07:35:49 +02:00
|
|
|
CustomData_from_bmesh_block(&bm->edata, &dm->edgeData, eed->head.data, i);
|
|
|
|
|
if (add_orig) *index = i;
|
2009-05-16 18:18:08 +02:00
|
|
|
}
|
2011-11-16 13:38:40 +01:00
|
|
|
bm->elem_index_dirty &= ~BM_EDGE;
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-01-18 16:09:27 +01:00
|
|
|
/* avoid this where possiblem, takes extra memory */
|
|
|
|
|
if (use_tessface) {
|
|
|
|
|
int *polyindex;
|
(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 12:06:25 +02:00
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
BM_mesh_elem_index_ensure(bm, BM_FACE);
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-01-18 16:09:27 +01:00
|
|
|
polyindex = dm->getTessFaceDataArray(dm, CD_POLYINDEX);
|
|
|
|
|
index = dm->getTessFaceDataArray(dm, CD_ORIGINDEX);
|
|
|
|
|
for(i = 0; i < dm->numTessFaceData; i++, index++, polyindex++) {
|
|
|
|
|
MFace *mf = &mface[i];
|
|
|
|
|
BMLoop **l = em->looptris[i];
|
|
|
|
|
efa = l[0]->f;
|
2009-05-16 18:18:08 +02:00
|
|
|
|
2012-02-12 11:51:45 +01: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 16:09:27 +01:00
|
|
|
mf->v4 = 0;
|
|
|
|
|
mf->mat_nr = efa->mat_nr;
|
2012-02-12 11:51:45 +01:00
|
|
|
mf->flag = BM_face_flag_to_mflag(efa);
|
2012-01-18 16:09:27 +01:00
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
*index = add_orig ? BM_elem_index_get(efa) : *(int*)CustomData_bmesh_get(&bm->pdata, efa->head.data, CD_ORIGINDEX);
|
|
|
|
|
*polyindex = BM_elem_index_get(efa);
|
2012-01-18 16:09:27 +01:00
|
|
|
|
|
|
|
|
loops_to_customdata_corners(bm, &dm->faceData, i, l, numCol, numTex);
|
|
|
|
|
test_index_face(mf, &dm->faceData, i, 3);
|
|
|
|
|
}
|
2009-05-16 18:18:08 +02: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 12:06:25 +02:00
|
|
|
|
2009-06-23 07:35:49 +02: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 12:06:25 +02:00
|
|
|
j = 0;
|
2012-02-12 11:51:45 +01:00
|
|
|
efa = BM_iter_new(&iter, bm, BM_FACES_OF_MESH, NULL);
|
|
|
|
|
for (i=0; efa; i++, efa=BM_iter_step(&iter), index++) {
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 12:06:25 +02:00
|
|
|
BMLoop *l;
|
|
|
|
|
MPoly *mp = &mpoly[i];
|
|
|
|
|
|
2012-02-12 11:51:45 +01:00
|
|
|
BM_elem_index_set(efa, i); /* set_inline */
|
2012-01-18 16:09:27 +01: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 12:06:25 +02:00
|
|
|
mp->totloop = efa->len;
|
2012-02-12 11:51:45 +01: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 12:06:25 +02:00
|
|
|
mp->loopstart = j;
|
|
|
|
|
mp->mat_nr = efa->mat_nr;
|
|
|
|
|
|
|
|
|
|
BM_ITER(l, &liter, bm, BM_LOOPS_OF_FACE, efa) {
|
2012-02-12 11:51:45 +01:00
|
|
|
mloop->v = BM_elem_index_get(l->v);
|
|
|
|
|
mloop->e = BM_elem_index_get(l->e);
|
2009-06-23 07:35:49 +02:00
|
|
|
CustomData_from_bmesh_block(&bm->ldata, &dm->loopData, l->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 12:06:25 +02:00
|
|
|
|
|
|
|
|
j++;
|
|
|
|
|
mloop++;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-23 07:35:49 +02:00
|
|
|
CustomData_from_bmesh_block(&bm->pdata, &dm->polyData, efa->head.data, i);
|
|
|
|
|
|
|
|
|
|
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 12:06:25 +02:00
|
|
|
}
|
2012-01-18 16:09:27 +01:00
|
|
|
bm->elem_index_dirty &= ~BM_FACE;
|
2009-05-16 18:18:08 +02:00
|
|
|
|
|
|
|
|
return dm;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-29 22:59:47 +01:00
|
|
|
static DerivedMesh *cddm_copy_ex(DerivedMesh *source, int faces_from_tessfaces)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_copy cddm");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
int numVerts = source->numVertData;
|
|
|
|
|
int numEdges = source->numEdgeData;
|
2011-11-30 19:03:56 +01:00
|
|
|
int numTessFaces = source->numTessFaceData;
|
(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 12:06:25 +02: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 05:28:02 +01:00
|
|
|
|
2009-11-25 14:11:44 +01:00
|
|
|
/* ensure these are created if they are made on demand */
|
|
|
|
|
source->getVertDataArray(source, CD_ORIGINDEX);
|
|
|
|
|
source->getEdgeDataArray(source, CD_ORIGINDEX);
|
2010-01-05 23:33:41 +01:00
|
|
|
source->getTessFaceDataArray(source, CD_ORIGINDEX);
|
2009-11-25 14:11:44 +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 05:28:02 +01:00
|
|
|
/* this initializes dm, and copies all non mvert/medge/mface layers */
|
2011-11-30 19:03:56 +01:00
|
|
|
DM_from_template(dm, source, DM_TYPE_CDDM, numVerts, numEdges, 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 12:06:25 +02: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 23:09:57 +01:00
|
|
|
dm->deformedOnly = source->deformedOnly;
|
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 23:06:57 +01: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 05:28:02 +01:00
|
|
|
|
|
|
|
|
CustomData_copy_data(&source->vertData, &dm->vertData, 0, 0, numVerts);
|
|
|
|
|
CustomData_copy_data(&source->edgeData, &dm->edgeData, 0, 0, numEdges);
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_copy_data(&source->faceData, &dm->faceData, 0, 0, numTessFaces);
|
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 05:28:02 +01:00
|
|
|
|
|
|
|
|
/* now add mvert/medge/mface layers */
|
|
|
|
|
cddm->mvert = source->dupVertArray(source);
|
|
|
|
|
cddm->medge = source->dupEdgeArray(source);
|
(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 12:06:25 +02:00
|
|
|
cddm->mface = source->dupTessFaceArray(source);
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
|
2006-12-12 22:29:09 +01: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);
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_ASSIGN, cddm->mface, 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 12:06:25 +02:00
|
|
|
|
2009-09-15 17:32:09 +02:00
|
|
|
if (!faces_from_tessfaces)
|
|
|
|
|
DM_DupPolys(source, dm);
|
2012-02-25 17:04:03 +01:00
|
|
|
else
|
2009-09-15 17:32:09 +02:00
|
|
|
CDDM_tessfaces_to_faces(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 12:06:25 +02:00
|
|
|
|
|
|
|
|
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
|
|
|
|
|
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
|
2011-11-13 16:13:59 +01:00
|
|
|
|
2012-01-19 20:23:25 +01:00
|
|
|
/* any callers that need tessface data can calculate it - campbell */
|
|
|
|
|
#if 0
|
2011-11-13 16:13:59 +01:00
|
|
|
/* BMESH_TODO: Find out why this is necessary (or else find a way to remove
|
2012-03-09 19:28:30 +01:00
|
|
|
* it). If it is necessary, add a comment explaining why. */
|
2012-03-02 17:05:54 +01:00
|
|
|
CDDM_recalc_tessellation((DerivedMesh *)cddm);
|
2012-01-19 20:23:25 +01:00
|
|
|
#endif
|
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
return dm;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2012-01-29 22:59:47 +01:00
|
|
|
DerivedMesh *CDDM_copy(DerivedMesh *source)
|
|
|
|
|
{
|
|
|
|
|
return cddm_copy_ex(source, 0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
DerivedMesh *CDDM_copy_from_tessface(DerivedMesh *source)
|
|
|
|
|
{
|
|
|
|
|
return cddm_copy_ex(source, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-20 11:18:55 +02:00
|
|
|
/* note, the CD_ORIGINDEX layers are all 0, so if there is a direct
|
2012-03-01 13:20:18 +01:00
|
|
|
* relationship between mesh data this needs to be set by the caller. */
|
2006-08-28 03:12:36 +02:00
|
|
|
DerivedMesh *CDDM_from_template(DerivedMesh *source,
|
2011-11-30 19:03:56 +01:00
|
|
|
int numVerts, int numEdges, int numTessFaces,
|
|
|
|
|
int numLoops, int numPolys)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = cdDM_create("CDDM_from_template dest");
|
|
|
|
|
DerivedMesh *dm = &cddm->dm;
|
|
|
|
|
|
2010-07-27 14:01:40 +02:00
|
|
|
/* ensure these are created if they are made on demand */
|
|
|
|
|
source->getVertDataArray(source, CD_ORIGINDEX);
|
|
|
|
|
source->getEdgeDataArray(source, CD_ORIGINDEX);
|
2010-09-04 07:31:25 +02:00
|
|
|
source->getTessFaceDataArray(source, CD_ORIGINDEX);
|
2010-07-27 14:01:40 +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 05:28:02 +01:00
|
|
|
/* this does a copy of all non mvert/medge/mface layers */
|
2011-11-30 19:03:56 +01:00
|
|
|
DM_from_template(dm, source, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces, numLoops, 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 05:28:02 +01:00
|
|
|
|
|
|
|
|
/* now add mvert/medge/mface layers */
|
2006-12-12 22:29:09 +01: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 19:03:56 +01: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 12:06:25 +02: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 22:29:09 +01:00
|
|
|
|
2009-11-04 21:23:48 +01:00
|
|
|
if(!CustomData_get_layer(&dm->vertData, CD_ORIGINDEX))
|
|
|
|
|
CustomData_add_layer(&dm->vertData, CD_ORIGINDEX, CD_CALLOC, NULL, numVerts);
|
|
|
|
|
if(!CustomData_get_layer(&dm->edgeData, CD_ORIGINDEX))
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
|
|
|
|
|
if(!CustomData_get_layer(&dm->faceData, CD_ORIGINDEX))
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
|
2011-11-13 16:13:59 +01:00
|
|
|
if(!CustomData_get_layer(&dm->faceData, CD_POLYINDEX))
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_POLYINDEX, CD_CALLOC, NULL, numTessFaces);
|
2009-11-04 21:23:48 +01:00
|
|
|
|
2006-12-12 22:29:09 +01: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 12:06:25 +02: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 05:28:02 +01:00
|
|
|
|
|
|
|
|
return dm;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_apply_vert_coords(DerivedMesh *dm, float (*vertCoords)[3])
|
|
|
|
|
{
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
MVert *vert;
|
2006-08-28 03:12:36 +02: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 05:28:02 +01:00
|
|
|
/* this will just return the pointer if it wasn't a referenced layer */
|
2011-12-19 09:26:53 +01: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 05:28:02 +01:00
|
|
|
cddm->mvert = vert;
|
|
|
|
|
|
|
|
|
|
for(i = 0; i < dm->numVertData; ++i, ++vert)
|
2011-11-07 02:38:32 +01:00
|
|
|
copy_v3_v3(vert->co, vertCoords[i]);
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
void CDDM_apply_vert_normals(DerivedMesh *dm, short (*vertNormals)[3])
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
MVert *vert;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
/* this will just return the pointer if it wasn't a referenced layer */
|
2011-12-19 09:26:53 +01: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 05:28:02 +01:00
|
|
|
cddm->mvert = vert;
|
|
|
|
|
|
|
|
|
|
for(i = 0; i < dm->numVertData; ++i, ++vert)
|
2011-09-12 06:14:12 +02:00
|
|
|
copy_v3_v3_short(vert->no, vertNormals[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 05:28:02 +01:00
|
|
|
}
|
|
|
|
|
|
2012-03-18 07:49:32 +01:00
|
|
|
void CDDM_calc_normals_mapping_ex(DerivedMesh *dm, const short only_face_normals)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
2011-04-15 03:19:13 +02:00
|
|
|
float (*face_nors)[3] = NULL;
|
2011-12-07 02:12:53 +01:00
|
|
|
|
2011-03-26 09:28:24 +01:00
|
|
|
if(dm->numVertData == 0) return;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
2011-12-07 02:12:53 +01: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 */
|
2012-03-18 07:49:32 +01: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 05:28:02 +01:00
|
|
|
/* we don't want to overwrite any referenced layers */
|
2011-12-19 09:26:53 +01:00
|
|
|
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
|
2012-03-18 07:49:32 +01:00
|
|
|
#endif
|
2011-11-13 16:13:59 +01:00
|
|
|
|
2012-01-19 18:51:52 +01:00
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
if (dm->numTessFaceData == 0) {
|
2012-03-02 17:05:54 +01:00
|
|
|
/* No tessellation on this mesh yet, need to calculate one.
|
2012-01-19 20:23:25 +01:00
|
|
|
*
|
|
|
|
|
* Important not to update face normals from polys since it
|
|
|
|
|
* interfears with assigning the new normal layer in the following code.
|
|
|
|
|
*/
|
2012-03-02 17:05:54 +01:00
|
|
|
CDDM_recalc_tessellation_ex(dm, FALSE);
|
2011-11-13 16:13:59 +01:00
|
|
|
}
|
|
|
|
|
else {
|
2012-03-02 17:05:54 +01:00
|
|
|
/* A tessellation already exists, it should always have a CD_POLYINDEX */
|
2011-11-13 16:13:59 +01:00
|
|
|
BLI_assert(CustomData_has_layer(&dm->faceData, CD_POLYINDEX));
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_free_layers(&dm->faceData, CD_NORMAL, dm->numTessFaceData);
|
2011-11-13 16:13:59 +01:00
|
|
|
}
|
|
|
|
|
|
2012-01-19 18:51:52 +01:00
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
face_nors = MEM_mallocN(sizeof(float)*3*dm->numTessFaceData, "face_nors");
|
2012-03-18 07:49:32 +01:00
|
|
|
|
2011-04-15 03:19:13 +02:00
|
|
|
/* calculate face normals */
|
2012-01-06 01:08:37 +01:00
|
|
|
mesh_calc_normals_mapping_ex(cddm->mvert, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
|
2012-03-18 07:49:32 +01:00
|
|
|
dm->numLoopData, dm->numPolyData, NULL, cddm->mface, dm->numTessFaceData,
|
|
|
|
|
CustomData_get_layer(&dm->faceData, CD_POLYINDEX), face_nors,
|
|
|
|
|
only_face_normals);
|
|
|
|
|
|
|
|
|
|
CustomData_add_layer(&dm->faceData, CD_NORMAL, CD_ASSIGN,
|
|
|
|
|
face_nors, dm->numTessFaceData);
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-19 18:51:52 +01:00
|
|
|
|
2012-03-18 07:49:32 +01:00
|
|
|
void CDDM_calc_normals_mapping(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
/* use this to skip calculating normals on original vert's, this may need to be changed */
|
|
|
|
|
const short only_face_normals = CustomData_is_referenced_layer(&dm->vertData, CD_MVERT);
|
2012-01-19 18:51:52 +01:00
|
|
|
|
2012-03-18 07:49:32 +01:00
|
|
|
CDDM_calc_normals_mapping_ex(dm, only_face_normals);
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2012-01-06 01:45:07 +01:00
|
|
|
/* bmesh note: this matches what we have in trunk */
|
|
|
|
|
void CDDM_calc_normals(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
float (*poly_nors)[3];
|
|
|
|
|
|
|
|
|
|
if(dm->numVertData == 0) return;
|
|
|
|
|
|
|
|
|
|
/* 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);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mesh_calc_normals(cddm->mvert, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
|
|
|
|
|
dm->numLoopData, dm->numPolyData, poly_nors);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_calc_normals_tessface(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
float (*face_nors)[3];
|
|
|
|
|
|
|
|
|
|
if(dm->numVertData == 0) return;
|
|
|
|
|
|
|
|
|
|
/* 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 */
|
|
|
|
|
face_nors = CustomData_get_layer(&dm->faceData, CD_NORMAL);
|
|
|
|
|
if (!face_nors) {
|
|
|
|
|
face_nors = CustomData_add_layer(&dm->faceData, CD_NORMAL, CD_CALLOC, NULL, dm->numTessFaceData);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mesh_calc_normals_tessface(cddm->mvert, dm->numVertData,
|
|
|
|
|
cddm->mface, dm->numTessFaceData, face_nors);
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-27 08:49:36 +01:00
|
|
|
#if 1
|
2011-12-29 10:15:06 +01:00
|
|
|
/* merge verts
|
|
|
|
|
*
|
|
|
|
|
* vtargetmap is a table that maps vertices to target vertices. a value of -1
|
|
|
|
|
* indicates a vertex is a target, and is to be kept.
|
|
|
|
|
*
|
|
|
|
|
* this frees dm, and returns a new one.
|
|
|
|
|
*
|
|
|
|
|
* this is a really horribly written function. ger. - joeedh
|
|
|
|
|
*
|
2012-03-02 17:05:54 +01:00
|
|
|
* note, CDDM_recalc_tessellation has to run on the returned DM if you want to access tessfaces.
|
2011-02-15 02:16:32 +01:00
|
|
|
*/
|
2012-01-03 10:37:57 +01:00
|
|
|
DerivedMesh *CDDM_merge_verts(DerivedMesh *dm, const int *vtargetmap)
|
2011-02-15 02:16:32 +01:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
CDDerivedMesh *cddm2 = NULL;
|
|
|
|
|
MVert *mv, *mvert = NULL;
|
|
|
|
|
BLI_array_declare(mvert);
|
2011-12-29 10:41:31 +01:00
|
|
|
MEdge *med, *medge = NULL;
|
2011-02-15 02:16:32 +01:00
|
|
|
BLI_array_declare(medge);
|
|
|
|
|
MPoly *mp, *mpoly = NULL;
|
|
|
|
|
BLI_array_declare(mpoly);
|
|
|
|
|
MLoop *ml, *mloop = NULL;
|
|
|
|
|
BLI_array_declare(mloop);
|
2011-02-27 08:49:36 +01:00
|
|
|
EdgeHash *ehash = BLI_edgehash_new();
|
2011-02-15 02:16:32 +01:00
|
|
|
int *newv = NULL, *newe = NULL, *newl = NULL;
|
|
|
|
|
int *oldv = NULL, *olde = NULL, *oldl = NULL, *oldp = NULL;
|
|
|
|
|
BLI_array_declare(oldv); BLI_array_declare(olde); BLI_array_declare(oldl); BLI_array_declare(oldp);
|
|
|
|
|
int i, j, c, totloop, totpoly;
|
|
|
|
|
|
|
|
|
|
totloop = dm->numLoopData;
|
|
|
|
|
totpoly = dm->numPolyData;
|
|
|
|
|
|
|
|
|
|
newv = MEM_callocN(sizeof(int)*dm->numVertData, "newv vtable CDDM_merge_verts");
|
|
|
|
|
newe = MEM_callocN(sizeof(int)*dm->numEdgeData, "newv etable CDDM_merge_verts");
|
|
|
|
|
newl = MEM_callocN(sizeof(int)*totloop, "newv ltable CDDM_merge_verts");
|
2011-02-27 08:49:36 +01:00
|
|
|
|
|
|
|
|
/*fill newl with destination vertex indices*/
|
2011-02-15 02:16:32 +01:00
|
|
|
mv = cddm->mvert;
|
|
|
|
|
c = 0;
|
|
|
|
|
for (i=0; i<dm->numVertData; i++, mv++) {
|
|
|
|
|
if (vtargetmap[i] == -1) {
|
|
|
|
|
BLI_array_append(oldv, i);
|
|
|
|
|
newv[i] = c++;
|
|
|
|
|
BLI_array_append(mvert, *mv);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-27 08:49:36 +01:00
|
|
|
/*now link target vertices to destination indices*/
|
|
|
|
|
for (i=0; i<dm->numVertData; i++) {
|
|
|
|
|
if (vtargetmap[i] != -1) {
|
|
|
|
|
newv[i] = newv[vtargetmap[i]];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-15 02:16:32 +01:00
|
|
|
/*find-replace merged vertices with target vertices*/
|
|
|
|
|
ml = cddm->mloop;
|
|
|
|
|
for (i=0; i<totloop; i++, ml++) {
|
2011-12-29 10:41:31 +01:00
|
|
|
if (vtargetmap[ml->v] != -1) {
|
2011-02-15 02:16:32 +01:00
|
|
|
ml->v = vtargetmap[ml->v];
|
2011-12-29 10:41:31 +01:00
|
|
|
}
|
2011-02-15 02:16:32 +01:00
|
|
|
}
|
2011-12-29 10:41:31 +01:00
|
|
|
|
2011-02-15 02:16:32 +01:00
|
|
|
/*now go through and fix edges and faces*/
|
2011-12-29 10:41:31 +01:00
|
|
|
med = cddm->medge;
|
2011-02-15 02:16:32 +01:00
|
|
|
c = 0;
|
2011-12-29 10:41:31 +01:00
|
|
|
for (i=0; i<dm->numEdgeData; i++, med++) {
|
2011-02-27 08:49:36 +01:00
|
|
|
|
2012-01-03 10:37:57 +01:00
|
|
|
if (LIKELY(med->v1 != med->v2)) {
|
2011-12-29 10:41:31 +01:00
|
|
|
const unsigned int v1 = (vtargetmap[med->v1] != -1) ? vtargetmap[med->v1] : med->v1;
|
|
|
|
|
const unsigned int v2 = (vtargetmap[med->v2] != -1) ? vtargetmap[med->v2] : med->v2;
|
|
|
|
|
void **eh_p= BLI_edgehash_lookup_p(ehash, v1, v2);
|
|
|
|
|
|
|
|
|
|
if (eh_p) {
|
|
|
|
|
newe[i] = GET_INT_FROM_POINTER(*eh_p);
|
|
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
BLI_array_append(olde, i);
|
|
|
|
|
newe[i] = c;
|
|
|
|
|
BLI_array_append(medge, *med);
|
|
|
|
|
BLI_edgehash_insert(ehash, v1, v2, SET_INT_IN_POINTER(c));
|
|
|
|
|
c++;
|
|
|
|
|
}
|
2011-02-27 08:49:36 +01:00
|
|
|
}
|
2011-12-29 10:41:31 +01:00
|
|
|
else {
|
|
|
|
|
newe[i] = -1;
|
2011-02-27 08:49:36 +01:00
|
|
|
}
|
2011-02-15 02:16:32 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mp = cddm->mpoly;
|
|
|
|
|
for (i=0; i<totpoly; i++, mp++) {
|
|
|
|
|
MPoly *mp2;
|
|
|
|
|
|
|
|
|
|
ml = cddm->mloop + mp->loopstart;
|
2011-12-29 10:41:31 +01:00
|
|
|
|
2011-02-15 02:16:32 +01:00
|
|
|
c = 0;
|
|
|
|
|
for (j=0; j<mp->totloop; j++, ml++) {
|
2011-12-29 10:41:31 +01:00
|
|
|
med = cddm->medge + ml->e;
|
2012-01-03 10:37:57 +01:00
|
|
|
if (LIKELY(med->v1 != med->v2)) {
|
|
|
|
|
newl[j+mp->loopstart] = BLI_array_count(mloop);
|
2011-02-27 08:49:36 +01:00
|
|
|
BLI_array_append(oldl, j+mp->loopstart);
|
2011-02-15 02:16:32 +01:00
|
|
|
BLI_array_append(mloop, *ml);
|
|
|
|
|
c++;
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-01-03 10:37:57 +01:00
|
|
|
|
|
|
|
|
if (UNLIKELY(c == 0)) {
|
2011-02-15 02:16:32 +01:00
|
|
|
continue;
|
2012-01-03 10:37:57 +01:00
|
|
|
}
|
2011-02-15 02:16:32 +01:00
|
|
|
|
2011-11-16 18:09:41 +01:00
|
|
|
mp2 = BLI_array_append_r(mpoly, *mp);
|
2011-02-15 02:16:32 +01:00
|
|
|
mp2->totloop = c;
|
|
|
|
|
mp2->loopstart = BLI_array_count(mloop) - c;
|
|
|
|
|
|
|
|
|
|
BLI_array_append(oldp, i);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*create new cddm*/
|
2011-04-15 03:19:13 +02:00
|
|
|
cddm2 = (CDDerivedMesh*) CDDM_from_template((DerivedMesh*)cddm, BLI_array_count(mvert), BLI_array_count(medge), 0, BLI_array_count(mloop), BLI_array_count(mpoly));
|
2011-02-15 02:16:32 +01:00
|
|
|
|
|
|
|
|
/*update edge indices and copy customdata*/
|
2011-12-29 10:41:31 +01:00
|
|
|
med = medge;
|
|
|
|
|
for (i=0; i<cddm2->dm.numEdgeData; i++, med++) {
|
|
|
|
|
if (newv[med->v1] != -1)
|
|
|
|
|
med->v1 = newv[med->v1];
|
|
|
|
|
if (newv[med->v2] != -1)
|
|
|
|
|
med->v2 = newv[med->v2];
|
2011-02-15 02:16:32 +01:00
|
|
|
|
|
|
|
|
CustomData_copy_data(&dm->edgeData, &cddm2->dm.edgeData, olde[i], i, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*update loop indices and copy customdata*/
|
2011-02-27 08:49:36 +01:00
|
|
|
ml = mloop;
|
2011-02-15 02:16:32 +01:00
|
|
|
for (i=0; i<cddm2->dm.numLoopData; i++, ml++) {
|
2011-02-27 08:49:36 +01:00
|
|
|
if (newe[ml->e] != -1)
|
|
|
|
|
ml->e = newe[ml->e];
|
|
|
|
|
if (newv[ml->v] != -1)
|
|
|
|
|
ml->v = newv[ml->v];
|
2011-02-15 02:16:32 +01:00
|
|
|
|
|
|
|
|
CustomData_copy_data(&dm->loopData, &cddm2->dm.loopData, oldl[i], i, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*copy vertex customdata*/
|
2011-02-27 08:49:36 +01:00
|
|
|
mv = mvert;
|
2011-02-15 02:16:32 +01:00
|
|
|
for (i=0; i<cddm2->dm.numVertData; i++, mv++) {
|
|
|
|
|
CustomData_copy_data(&dm->vertData, &cddm2->dm.vertData, oldv[i], i, 1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*copy poly customdata*/
|
2011-02-27 08:49:36 +01:00
|
|
|
mp = mpoly;
|
2011-02-15 02:16:32 +01:00
|
|
|
for (i=0; i<cddm2->dm.numPolyData; i++, mp++) {
|
|
|
|
|
CustomData_copy_data(&dm->polyData, &cddm2->dm.polyData, oldp[i], i, 1);
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-27 08:49:36 +01:00
|
|
|
/*copy over data. CustomData_add_layer can do this, need to look it up.*/
|
|
|
|
|
memcpy(cddm2->mvert, mvert, sizeof(MVert)*BLI_array_count(mvert));
|
|
|
|
|
memcpy(cddm2->medge, medge, sizeof(MEdge)*BLI_array_count(medge));
|
|
|
|
|
memcpy(cddm2->mloop, mloop, sizeof(MLoop)*BLI_array_count(mloop));
|
|
|
|
|
memcpy(cddm2->mpoly, mpoly, sizeof(MPoly)*BLI_array_count(mpoly));
|
|
|
|
|
BLI_array_free(mvert); BLI_array_free(medge); BLI_array_free(mloop); BLI_array_free(mpoly);
|
2011-02-15 02:16:32 +01:00
|
|
|
|
|
|
|
|
if (newv)
|
|
|
|
|
MEM_freeN(newv);
|
|
|
|
|
if (newe)
|
|
|
|
|
MEM_freeN(newe);
|
|
|
|
|
if (newl)
|
|
|
|
|
MEM_freeN(newl);
|
|
|
|
|
if (oldv)
|
|
|
|
|
MEM_freeN(oldv);
|
|
|
|
|
if (olde)
|
|
|
|
|
MEM_freeN(olde);
|
|
|
|
|
if (oldl)
|
|
|
|
|
MEM_freeN(oldl);
|
|
|
|
|
if (oldp)
|
|
|
|
|
MEM_freeN(oldp);
|
2011-02-27 08:49:36 +01:00
|
|
|
if (ehash)
|
|
|
|
|
BLI_edgehash_free(ehash, NULL);
|
|
|
|
|
|
|
|
|
|
/*free old derivedmesh*/
|
2011-02-15 02:16:32 +01:00
|
|
|
dm->needsFree = 1;
|
|
|
|
|
dm->release(dm);
|
|
|
|
|
|
|
|
|
|
return (DerivedMesh*)cddm2;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-01-06 03:59:28 +01:00
|
|
|
void CDDM_calc_edges_tessface(DerivedMesh *dm)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
2006-08-28 03:12:36 +02:00
|
|
|
CustomData edgeData;
|
|
|
|
|
EdgeHashIterator *ehi;
|
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 05:28:02 +01:00
|
|
|
MFace *mf = cddm->mface;
|
2006-08-28 03:12:36 +02:00
|
|
|
MEdge *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 05:28:02 +01:00
|
|
|
EdgeHash *eh = BLI_edgehash_new();
|
2011-11-30 19:03:56 +01:00
|
|
|
int i, *index, numEdges, maxFaces = dm->numTessFaceData;
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
for (i = 0; i < maxFaces; i++, mf++) {
|
|
|
|
|
if (!BLI_edgehash_haskey(eh, mf->v1, mf->v2))
|
|
|
|
|
BLI_edgehash_insert(eh, mf->v1, mf->v2, NULL);
|
|
|
|
|
if (!BLI_edgehash_haskey(eh, mf->v2, mf->v3))
|
|
|
|
|
BLI_edgehash_insert(eh, mf->v2, mf->v3, NULL);
|
|
|
|
|
|
|
|
|
|
if (mf->v4) {
|
|
|
|
|
if (!BLI_edgehash_haskey(eh, mf->v3, mf->v4))
|
|
|
|
|
BLI_edgehash_insert(eh, mf->v3, mf->v4, NULL);
|
|
|
|
|
if (!BLI_edgehash_haskey(eh, mf->v4, mf->v1))
|
|
|
|
|
BLI_edgehash_insert(eh, mf->v4, mf->v1, NULL);
|
|
|
|
|
} else {
|
|
|
|
|
if (!BLI_edgehash_haskey(eh, mf->v3, mf->v1))
|
|
|
|
|
BLI_edgehash_insert(eh, mf->v3, mf->v1, 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 05:28:02 +01:00
|
|
|
numEdges = BLI_edgehash_size(eh);
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
/* write new edges into a temporary CustomData */
|
|
|
|
|
memset(&edgeData, 0, sizeof(edgeData));
|
2006-12-12 22:29:09 +01:00
|
|
|
CustomData_add_layer(&edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
|
|
|
|
|
CustomData_add_layer(&edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
|
2006-11-23 18:35:45 +01:00
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
ehi = BLI_edgehashIterator_new(eh);
|
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 05:28:02 +01:00
|
|
|
med = CustomData_get_layer(&edgeData, CD_MEDGE);
|
2006-12-12 22:29:09 +01:00
|
|
|
index = CustomData_get_layer(&edgeData, CD_ORIGINDEX);
|
2006-08-28 03:12:36 +02:00
|
|
|
for(i = 0; !BLI_edgehashIterator_isDone(ehi);
|
2010-03-22 10:30:00 +01:00
|
|
|
BLI_edgehashIterator_step(ehi), ++i, ++med, ++index) {
|
2011-12-28 11:06:10 +01:00
|
|
|
BLI_edgehashIterator_getKey(ehi, &med->v1, &med->v2);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
med->flag = ME_EDGEDRAW|ME_EDGERENDER;
|
2006-11-23 18:35:45 +01:00
|
|
|
*index = ORIGINDEX_NONE;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
BLI_edgehashIterator_free(ehi);
|
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
/* free old CustomData and assign new one */
|
RNA
* Mesh.add_geometry, Mesh.update and make indices editable. This
is without checking if they are valid still, no time now to
implement this.
* Also fix warnings in rna_ui.c, and a bug in CDDM_calc_edges.
Example code:
co = [0.0, 0.0, 0.0] + [1.0, 0.0, 0.0] + [0.0, 1.0, 0.0] + [1.0, 1.0, 0.0]
faces = [0, 1, 2, 0] + [1, 3, 2, 0]
mesh.add_geometry(4, 0, 2)
mesh.verts.foreach_set("co", co)
mesh.faces.foreach_set("verts", faces)
mesh.update()
2009-07-01 14:19:00 +02:00
|
|
|
CustomData_free(&dm->edgeData, dm->numEdgeData);
|
2006-08-28 03:12:36 +02:00
|
|
|
dm->edgeData = edgeData;
|
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 05:28:02 +01:00
|
|
|
dm->numEdgeData = numEdges;
|
|
|
|
|
|
|
|
|
|
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
|
2006-08-28 03:12:36 +02:00
|
|
|
|
|
|
|
|
BLI_edgehash_free(eh, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-06 03:59:28 +01:00
|
|
|
/* warning, this uses existing edges but CDDM_calc_edges_tessface() doesn't */
|
|
|
|
|
void CDDM_calc_edges(DerivedMesh *dm)
|
2009-09-11 12:21:54 +02:00
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
CustomData edgeData;
|
|
|
|
|
EdgeHashIterator *ehi;
|
|
|
|
|
MPoly *mp = cddm->mpoly;
|
|
|
|
|
MLoop *ml;
|
|
|
|
|
MEdge *med;
|
|
|
|
|
EdgeHash *eh = BLI_edgehash_new();
|
|
|
|
|
int v1, v2;
|
|
|
|
|
int *eindex;
|
2011-11-16 18:09:41 +01:00
|
|
|
int i, j, *index, numEdges = cddm->dm.numEdgeData, maxFaces = dm->numPolyData;
|
2009-09-11 12:21:54 +02:00
|
|
|
|
|
|
|
|
eindex = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
|
|
|
|
|
|
|
|
|
|
med = cddm->medge;
|
|
|
|
|
if (med) {
|
|
|
|
|
for (i=0; i < numEdges; i++, med++) {
|
|
|
|
|
BLI_edgehash_insert(eh, med->v1, med->v2, SET_INT_IN_POINTER(i+1));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (i=0; i < maxFaces; i++, mp++) {
|
|
|
|
|
ml = cddm->mloop + mp->loopstart;
|
|
|
|
|
for (j=0; j<mp->totloop; j++, ml++) {
|
|
|
|
|
v1 = ml->v;
|
2011-12-28 08:10:27 +01:00
|
|
|
v2 = ME_POLY_LOOP_NEXT(cddm->mloop, mp, j)->v;
|
2009-09-11 12:21:54 +02:00
|
|
|
if (!BLI_edgehash_haskey(eh, v1, v2)) {
|
|
|
|
|
BLI_edgehash_insert(eh, v1, v2, NULL);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
numEdges = BLI_edgehash_size(eh);
|
|
|
|
|
|
|
|
|
|
/* write new edges into a temporary CustomData */
|
|
|
|
|
memset(&edgeData, 0, sizeof(edgeData));
|
|
|
|
|
CustomData_add_layer(&edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
|
|
|
|
|
CustomData_add_layer(&edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
|
|
|
|
|
|
|
|
|
|
ehi = BLI_edgehashIterator_new(eh);
|
|
|
|
|
med = CustomData_get_layer(&edgeData, CD_MEDGE);
|
|
|
|
|
index = CustomData_get_layer(&edgeData, CD_ORIGINDEX);
|
|
|
|
|
for(i = 0; !BLI_edgehashIterator_isDone(ehi);
|
|
|
|
|
BLI_edgehashIterator_step(ehi), ++i, ++med, ++index) {
|
2011-12-28 11:06:10 +01:00
|
|
|
BLI_edgehashIterator_getKey(ehi, &med->v1, &med->v2);
|
2009-09-11 12:21:54 +02:00
|
|
|
j = GET_INT_FROM_POINTER(BLI_edgehashIterator_getValue(ehi));
|
|
|
|
|
|
|
|
|
|
med->flag = ME_EDGEDRAW|ME_EDGERENDER;
|
|
|
|
|
*index = j==0 ? ORIGINDEX_NONE : eindex[j-1];
|
|
|
|
|
|
|
|
|
|
BLI_edgehashIterator_setValue(ehi, SET_INT_IN_POINTER(i));
|
|
|
|
|
}
|
|
|
|
|
BLI_edgehashIterator_free(ehi);
|
|
|
|
|
|
|
|
|
|
/* free old CustomData and assign new one */
|
|
|
|
|
CustomData_free(&dm->edgeData, dm->numEdgeData);
|
|
|
|
|
dm->edgeData = edgeData;
|
|
|
|
|
dm->numEdgeData = numEdges;
|
|
|
|
|
|
|
|
|
|
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
|
|
|
|
|
|
|
|
|
|
mp = cddm->mpoly;
|
|
|
|
|
for (i=0; i < maxFaces; i++, mp++) {
|
|
|
|
|
ml = cddm->mloop + mp->loopstart;
|
|
|
|
|
for (j=0; j<mp->totloop; j++, ml++) {
|
|
|
|
|
v1 = ml->v;
|
2011-12-28 08:10:27 +01:00
|
|
|
v2 = ME_POLY_LOOP_NEXT(cddm->mloop, mp, j)->v;
|
2009-09-11 12:21:54 +02:00
|
|
|
ml->e = GET_INT_FROM_POINTER(BLI_edgehash_lookup(eh, v1, v2));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_edgehash_free(eh, 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 05:28:02 +01:00
|
|
|
void CDDM_lower_num_verts(DerivedMesh *dm, int numVerts)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
if (numVerts < dm->numVertData)
|
2006-12-12 22:29:09 +01: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 05:28:02 +01:00
|
|
|
|
|
|
|
|
dm->numVertData = numVerts;
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
void CDDM_lower_num_edges(DerivedMesh *dm, int numEdges)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
if (numEdges < dm->numEdgeData)
|
2006-12-12 22:29:09 +01: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 05:28:02 +01:00
|
|
|
|
|
|
|
|
dm->numEdgeData = numEdges;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-12-31 13:58:03 +01:00
|
|
|
void CDDM_lower_num_tessfaces(DerivedMesh *dm, int numTessFaces)
|
|
|
|
|
{
|
|
|
|
|
if (numTessFaces < dm->numTessFaceData)
|
|
|
|
|
CustomData_free_elem(&dm->faceData, numTessFaces, dm->numTessFaceData-numTessFaces);
|
|
|
|
|
|
|
|
|
|
dm->numTessFaceData = numTessFaces;
|
|
|
|
|
}
|
|
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
void CDDM_lower_num_polys(DerivedMesh *dm, int numPolys)
|
2006-08-28 03:12:36 +02:00
|
|
|
{
|
2011-11-30 19:03:56 +01:00
|
|
|
if (numPolys < dm->numPolyData)
|
|
|
|
|
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 05:28:02 +01:00
|
|
|
|
2011-11-30 19:03:56 +01:00
|
|
|
dm->numPolyData = numPolys;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2012-02-07 02:13:04 +01:00
|
|
|
/* mesh element access functions */
|
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
MVert *CDDM_get_vert(DerivedMesh *dm, int 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 05:28:02 +01:00
|
|
|
return &((CDDerivedMesh*)dm)->mvert[index];
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEdge *CDDM_get_edge(DerivedMesh *dm, int 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 05:28:02 +01:00
|
|
|
return &((CDDerivedMesh*)dm)->medge[index];
|
2006-08-28 03:12:36 +02: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 12:06:25 +02:00
|
|
|
MFace *CDDM_get_tessface(DerivedMesh *dm, int index)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
return &((CDDerivedMesh*)dm)->mface[index];
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2012-02-07 02:13:04 +01:00
|
|
|
MLoop *CDDM_get_loop(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
|
|
|
|
return &((CDDerivedMesh*)dm)->mloop[index];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MPoly *CDDM_get_poly(DerivedMesh *dm, int index)
|
|
|
|
|
{
|
|
|
|
|
return &((CDDerivedMesh*)dm)->mpoly[index];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* array access functions */
|
|
|
|
|
|
2006-08-28 03:12:36 +02:00
|
|
|
MVert *CDDM_get_verts(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 05:28:02 +01:00
|
|
|
return ((CDDerivedMesh*)dm)->mvert;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
MEdge *CDDM_get_edges(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 05:28:02 +01:00
|
|
|
return ((CDDerivedMesh*)dm)->medge;
|
2006-08-28 03:12:36 +02: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 12:06:25 +02:00
|
|
|
MFace *CDDM_get_tessfaces(DerivedMesh *dm)
|
2006-08-28 03:12:36 +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 05:28:02 +01:00
|
|
|
return ((CDDerivedMesh*)dm)->mface;
|
2006-08-28 03:12:36 +02:00
|
|
|
}
|
|
|
|
|
|
2011-02-27 08:49:36 +01:00
|
|
|
MLoop *CDDM_get_loops(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
return ((CDDerivedMesh*)dm)->mloop;
|
|
|
|
|
}
|
|
|
|
|
|
2011-02-27 07:19:40 +01:00
|
|
|
MPoly *CDDM_get_polys(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
return ((CDDerivedMesh*)dm)->mpoly;
|
|
|
|
|
}
|
|
|
|
|
|
(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 12:06:25 +02:00
|
|
|
void CDDM_tessfaces_to_faces(DerivedMesh *dm)
|
|
|
|
|
{
|
|
|
|
|
/*converts mfaces to mpolys/mloops*/
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
MFace *mf;
|
|
|
|
|
MEdge *me;
|
|
|
|
|
EdgeHash *eh = BLI_edgehash_new();
|
2011-11-23 18:48:55 +01:00
|
|
|
int i, totloop;
|
2012-03-20 01:59:51 +01:00
|
|
|
|
|
|
|
|
/* ... on second thaughts, better comment this and assume caller knows edge state. */
|
|
|
|
|
#if 0
|
|
|
|
|
/* ensure we have all the edges we need */
|
2012-01-06 03:59:28 +01:00
|
|
|
CDDM_calc_edges_tessface(dm);
|
2012-03-20 02:33:24 +01:00
|
|
|
#else
|
|
|
|
|
# ifndef NDEBUG
|
|
|
|
|
{
|
|
|
|
|
/* ensure we have correct edges on non release builds */
|
|
|
|
|
i = cddm->dm.numEdgeData;
|
|
|
|
|
CDDM_calc_edges_tessface(dm);
|
|
|
|
|
BLI_assert(cddm->dm.numEdgeData == i);
|
|
|
|
|
}
|
|
|
|
|
# endif
|
2012-03-20 01:59:51 +01:00
|
|
|
#endif
|
subsurf works now! YES! take *that* subsurf_ccg.cscons/scons.py BF_QUICK=bf_python,bf_blenkernel,bf_blenlib,bf_blenloader,bf_editors_mesh,bf_bmesh,bf_editors_space_view3d,bf_editors_transform,bf_makesdna,bf_makesrna,bf_dna,bf_rn,bf_bmesh,bf_editors_object,editors_uvedit,editors_space_image,editors_screen,editors_space_screen,editors_space_api,bf_windowmanager,bf_wm still an issue with some modifier combinations though, and I think there's some memory corruption going on, need to valgrind it.
2009-08-25 12:21:10 +02:00
|
|
|
|
|
|
|
|
/*build edge hash*/
|
(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 12:06:25 +02:00
|
|
|
me = cddm->medge;
|
|
|
|
|
for (i=0; i<cddm->dm.numEdgeData; i++, me++) {
|
|
|
|
|
BLI_edgehash_insert(eh, me->v1, me->v2, SET_INT_IN_POINTER(i));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
mf = cddm->mface;
|
|
|
|
|
totloop = 0;
|
2011-11-30 19:03:56 +01:00
|
|
|
for (i=0; i<cddm->dm.numTessFaceData; i++, mf++) {
|
(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 12:06:25 +02:00
|
|
|
totloop += mf->v4 ? 4 : 3;
|
|
|
|
|
}
|
|
|
|
|
|
2009-06-16 22:08:40 +02:00
|
|
|
CustomData_free(&cddm->dm.polyData, cddm->dm.numPolyData);
|
|
|
|
|
CustomData_free(&cddm->dm.loopData, cddm->dm.numLoopData);
|
|
|
|
|
|
(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 12:06:25 +02:00
|
|
|
cddm->dm.numLoopData = totloop;
|
2011-11-30 19:03:56 +01:00
|
|
|
cddm->dm.numPolyData = cddm->dm.numTessFaceData;
|
2009-06-16 22:08:40 +02:00
|
|
|
|
2011-11-23 18:48:55 +01:00
|
|
|
if (totloop) {
|
|
|
|
|
MLoop *ml;
|
|
|
|
|
MPoly *mp;
|
|
|
|
|
int l, *polyindex;
|
|
|
|
|
|
|
|
|
|
cddm->mloop = MEM_callocN(sizeof(MLoop)*totloop, "cddm->mloop in CDDM_tessfaces_to_faces");
|
2011-11-30 19:03:56 +01:00
|
|
|
cddm->mpoly = MEM_callocN(sizeof(MPoly)*cddm->dm.numTessFaceData, "cddm->mpoly in CDDM_tessfaces_to_faces");
|
2011-11-23 18:48:55 +01:00
|
|
|
|
|
|
|
|
CustomData_add_layer(&cddm->dm.loopData, CD_MLOOP, CD_ASSIGN, cddm->mloop, totloop);
|
|
|
|
|
CustomData_add_layer(&cddm->dm.polyData, CD_MPOLY, CD_ASSIGN, cddm->mpoly, cddm->dm.numPolyData);
|
|
|
|
|
CustomData_merge(&cddm->dm.faceData, &cddm->dm.polyData,
|
2011-11-30 19:03:56 +01:00
|
|
|
CD_MASK_ORIGINDEX, CD_DUPLICATE, cddm->dm.numTessFaceData);
|
2011-11-23 18:48:55 +01:00
|
|
|
|
|
|
|
|
polyindex = CustomData_get_layer(&cddm->dm.faceData, CD_POLYINDEX);
|
|
|
|
|
|
|
|
|
|
mf = cddm->mface;
|
|
|
|
|
mp = cddm->mpoly;
|
|
|
|
|
ml = cddm->mloop;
|
|
|
|
|
l = 0;
|
2012-03-20 02:33:24 +01:00
|
|
|
for (i=0; i<cddm->dm.numTessFaceData; i++, mf++, mp++, polyindex++) {
|
2011-11-23 18:48:55 +01:00
|
|
|
mp->flag = mf->flag;
|
|
|
|
|
mp->loopstart = l;
|
|
|
|
|
mp->mat_nr = mf->mat_nr;
|
|
|
|
|
mp->totloop = mf->v4 ? 4 : 3;
|
|
|
|
|
|
|
|
|
|
ml->v = mf->v1;
|
|
|
|
|
ml->e = GET_INT_FROM_POINTER(BLI_edgehash_lookup(eh, mf->v1, mf->v2));
|
|
|
|
|
ml++, l++;
|
2009-06-16 22:08:40 +02:00
|
|
|
|
2011-11-23 18:48:55 +01:00
|
|
|
ml->v = mf->v2;
|
|
|
|
|
ml->e = GET_INT_FROM_POINTER(BLI_edgehash_lookup(eh, mf->v2, mf->v3));
|
|
|
|
|
ml++, l++;
|
(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 12:06:25 +02:00
|
|
|
|
2011-11-23 18:48:55 +01:00
|
|
|
ml->v = mf->v3;
|
|
|
|
|
ml->e = GET_INT_FROM_POINTER(BLI_edgehash_lookup(eh, mf->v3, mf->v4?mf->v4:mf->v1));
|
|
|
|
|
ml++, l++;
|
(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 12:06:25 +02:00
|
|
|
|
2011-11-23 18:48:55 +01:00
|
|
|
if (mf->v4) {
|
|
|
|
|
ml->v = mf->v4;
|
|
|
|
|
ml->e = GET_INT_FROM_POINTER(BLI_edgehash_lookup(eh, mf->v4, mf->v1));
|
|
|
|
|
ml++, l++;
|
|
|
|
|
}
|
(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 12:06:25 +02:00
|
|
|
|
2011-11-23 18:48:55 +01:00
|
|
|
*polyindex = 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 12:06:25 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
BLI_edgehash_free(eh, NULL);
|
|
|
|
|
}
|
|
|
|
|
|
2009-09-11 12:21:54 +02:00
|
|
|
void CDDM_set_mvert(DerivedMesh *dm, MVert *mvert)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
2011-04-23 01:37:58 +02:00
|
|
|
|
|
|
|
|
if (!CustomData_has_layer(&dm->vertData, CD_MVERT))
|
|
|
|
|
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_ASSIGN, mvert, dm->numVertData);
|
|
|
|
|
|
2009-09-11 12:21:54 +02:00
|
|
|
cddm->mvert = mvert;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_set_medge(DerivedMesh *dm, MEdge *medge)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
2010-01-05 23:33:41 +01:00
|
|
|
|
2011-04-23 01:37:58 +02:00
|
|
|
if (!CustomData_has_layer(&dm->edgeData, CD_MEDGE))
|
|
|
|
|
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_ASSIGN, medge, dm->numEdgeData);
|
|
|
|
|
|
2009-09-11 12:21:54 +02:00
|
|
|
cddm->medge = medge;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void CDDM_set_mface(DerivedMesh *dm, MFace *mface)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
2009-01-06 19:59:03 +01:00
|
|
|
|
2011-04-23 01:37:58 +02:00
|
|
|
if (!CustomData_has_layer(&dm->faceData, CD_MFACE))
|
2011-11-30 19:03:56 +01:00
|
|
|
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_ASSIGN, mface, dm->numTessFaceData);
|
2011-04-23 01:37:58 +02:00
|
|
|
|
2010-01-05 23:33:41 +01:00
|
|
|
cddm->mface = mface;
|
2009-01-06 19:59:03 +01:00
|
|
|
}
|
2012-02-29 16:00:37 +01:00
|
|
|
|
|
|
|
|
void CDDM_set_mloop(DerivedMesh *dm, MLoop *mloop)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
|
{
|
|
|
|
|
CDDerivedMesh *cddm = (CDDerivedMesh*)dm;
|
|
|
|
|
|
|
|
|
|
if (!CustomData_has_layer(&dm->polyData, CD_MPOLY))
|
|
|
|
|
CustomData_add_layer(&dm->polyData, CD_MPOLY, CD_ASSIGN, mpoly, dm->numPolyData);
|
|
|
|
|
|
|
|
|
|
cddm->mpoly = mpoly;
|
|
|
|
|
}
|
