2011-02-18 13:05:18 +00:00
|
|
|
/*
|
2005-03-27 20:34:18 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
2008-04-16 22:40:48 +00:00
|
|
|
* of the License, or (at your option) any later version.
|
2005-03-27 20:34:18 +00:00
|
|
|
*
|
|
|
|
* 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,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2005-03-27 20:34:18 +00:00
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
|
|
|
|
* All rights reserved.
|
|
|
|
*/
|
|
|
|
|
2012-02-17 18:59:41 +00:00
|
|
|
#pragma once
|
2005-03-27 20:34:18 +00:00
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
* \ingroup bke
|
2013-09-12 03:02:50 +00:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* Basic design of the DerivedMesh system:
|
|
|
|
*
|
|
|
|
* DerivedMesh is a common set of interfaces for mesh systems.
|
|
|
|
*
|
2012-06-27 17:48:39 +00:00
|
|
|
* There are three main mesh data structures in Blender:
|
|
|
|
* #Mesh, #CDDerivedMesh and #BMesh.
|
|
|
|
*
|
2018-06-01 18:19:39 +02:00
|
|
|
* These, and a few others, all implement DerivedMesh interfaces,
|
|
|
|
* which contains unified drawing interfaces, a few utility interfaces,
|
|
|
|
* and a bunch of read-only interfaces intended mostly for conversion from
|
2012-03-03 20:19:11 +00:00
|
|
|
* one format to another.
|
|
|
|
*
|
|
|
|
* All Mesh structures in blender make use of CustomData, which is used to store
|
|
|
|
* per-element attributes and interpolate them (e.g. uvs, vcols, vgroups, etc).
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* Mesh is the "serialized" structure, used for storing object-mode mesh data
|
|
|
|
* and also for saving stuff to disk. Its interfaces are also what DerivedMesh
|
|
|
|
* uses to communicate with.
|
2018-06-01 18:19:39 +02:00
|
|
|
*
|
2012-03-03 20:19:11 +00:00
|
|
|
* CDDM is a little mesh library, that uses Mesh data structures in the backend.
|
|
|
|
* It's mostly used for modifiers, and has the advantages of not taking much
|
|
|
|
* resources.
|
|
|
|
*
|
|
|
|
* BMesh is a full-on brep, used for editmode, some modifiers, etc. It's much
|
|
|
|
* more capable (if memory-intensive) then CDDM.
|
|
|
|
*
|
|
|
|
* DerivedMesh is somewhat hackish. Many places assumes that a DerivedMesh is
|
|
|
|
* a CDDM (most of the time by simply copying it and converting it to one).
|
|
|
|
* CDDM is the original structure for modifiers, but has since been superseded
|
|
|
|
* by BMesh, at least for the foreseeable future.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2012-03-09 00:41:09 +00:00
|
|
|
* Note: This structure is read-only, for all practical purposes.
|
2009-07-17 01:57:12 +00:00
|
|
|
* At some point in the future, we may want to consider
|
|
|
|
* creating a replacement structure that implements a proper
|
|
|
|
* abstract mesh kernel interface. Or, we can leave this
|
|
|
|
* as it is and stick with using BMesh and CDDM.
|
|
|
|
*/
|
|
|
|
|
2006-11-11 16:38:37 +00:00
|
|
|
#include "DNA_customdata_types.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "DNA_defs.h"
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
#include "DNA_meshdata_types.h"
|
|
|
|
|
2013-09-01 15:01:15 +00:00
|
|
|
#include "BLI_compiler_attrs.h"
|
|
|
|
|
2009-05-23 03:24:15 +00:00
|
|
|
#include "BKE_bvhutils.h"
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BKE_customdata.h"
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2020-03-02 15:07:49 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
extern "C" {
|
|
|
|
#endif
|
|
|
|
|
2019-01-28 21:08:24 +11:00
|
|
|
struct BMEditMesh;
|
2012-05-10 20:33:09 +00:00
|
|
|
struct CCGElem;
|
|
|
|
struct CCGKey;
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
struct CustomData_MeshMasks;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Depsgraph;
|
2006-08-28 01:12:36 +00:00
|
|
|
struct MEdge;
|
|
|
|
struct MFace;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct MVert;
|
|
|
|
struct Mesh;
|
2005-07-26 00:45:19 +00:00
|
|
|
struct ModifierData;
|
2019-01-28 21:08:24 +11:00
|
|
|
struct Object;
|
|
|
|
struct Scene;
|
2005-03-27 20:34:18 +00:00
|
|
|
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
/*
|
2012-03-18 07:38:51 +00:00
|
|
|
* Note: all mface interfaces now officially operate on tessellated data.
|
2012-03-03 20:19:11 +00:00
|
|
|
* Also, the mface origindex layer indexes mpolys, not mfaces.
|
|
|
|
*/
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
|
2012-03-06 02:40:08 +00:00
|
|
|
/* keep in sync with MFace/MPoly types */
|
|
|
|
typedef struct DMFlagMat {
|
|
|
|
short mat_nr;
|
|
|
|
char flag;
|
|
|
|
} DMFlagMat;
|
|
|
|
|
2010-01-06 12:05:46 +00:00
|
|
|
typedef enum DerivedMeshType {
|
|
|
|
DM_TYPE_CDDM,
|
2019-04-16 16:40:47 +02:00
|
|
|
DM_TYPE_CCGDM,
|
2010-01-06 12:05:46 +00:00
|
|
|
} DerivedMeshType;
|
|
|
|
|
Fix [#30234] Various problems with CD layers and tesselation, related to modifiers stack.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
2012-03-18 22:06:57 +00:00
|
|
|
typedef enum DMDirtyFlag {
|
|
|
|
/* dm has valid tessellated faces, but tessellated CDDATA need to be updated. */
|
|
|
|
DM_DIRTY_TESS_CDLAYERS = 1 << 0,
|
2013-05-30 17:36:43 +00:00
|
|
|
|
|
|
|
/* check this with modifier dependsOnNormals callback to see if normals need recalculation */
|
Remove Blender Internal and legacy viewport from Blender 2.8.
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
2018-04-19 17:34:44 +02:00
|
|
|
DM_DIRTY_NORMALS = 1 << 1,
|
2013-05-30 17:36:43 +00:00
|
|
|
} DMDirtyFlag;
|
Fix [#30234] Various problems with CD layers and tesselation, related to modifiers stack.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
2012-03-18 22:06:57 +00:00
|
|
|
|
2005-03-27 20:34:18 +00:00
|
|
|
typedef struct DerivedMesh DerivedMesh;
|
|
|
|
struct DerivedMesh {
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Private DerivedMesh data, only for internal DerivedMesh use */
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
CustomData vertData, edgeData, faceData, loopData, polyData;
|
2011-11-30 18:03:56 +00:00
|
|
|
int numVertData, numEdgeData, numTessFaceData, numLoopData, numPolyData;
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
int needsFree; /* checked on ->release, is set to 0 for cached results */
|
Particles
=========
Merge of the famous particle patch by Janne Karhu, a full rewrite
of the Blender particle system. This includes:
- Emitter, Hair and Reactor particle types.
- Newtonian, Keyed and Boids physics.
- Various particle visualisation and rendering types.
- Vertex group and texture control for various properties.
- Interpolated child particles from parents.
- Hair editing with combing, growing, cutting, .. .
- Explode modifier.
- Harmonic, Magnetic fields, and multiple falloff types.
.. and lots of other things, some more info is here:
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite
http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc
The new particle system cannot be backwards compatible. Old particle
systems are being converted to the new system, but will require
tweaking to get them looking the same as before.
Point Cache
===========
The new system to replace manual baking, based on automatic caching
on disk. This is currently used by softbodies and the particle system.
See the Cache API section on:
http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint
Documentation
=============
These new features still need good docs for the release logs, help
for this is appreciated.
2007-11-26 22:09:57 +00:00
|
|
|
int deformedOnly; /* set by modifier stack if only deformed from original */
|
2010-01-06 12:05:46 +00:00
|
|
|
DerivedMeshType type;
|
Fix [#30234] Various problems with CD layers and tesselation, related to modifiers stack.
Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
2012-03-18 22:06:57 +00:00
|
|
|
DMDirtyFlag dirty;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
/**
|
|
|
|
* \warning Typical access is done via #getLoopTriArray, #getNumLoopTri.
|
|
|
|
*/
|
|
|
|
struct {
|
2019-04-27 12:07:07 +10:00
|
|
|
/* WARNING! swapping between array (ready-to-be-used data) and array_wip
|
|
|
|
* (where data is actually computed) shall always be protected by same
|
|
|
|
* lock as one used for looptris computing. */
|
2017-09-19 13:57:46 +02:00
|
|
|
struct MLoopTri *array, *array_wip;
|
2015-07-17 03:36:03 +10:00
|
|
|
int num;
|
|
|
|
int num_alloc;
|
|
|
|
} looptris;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-01-10 04:43:31 +00:00
|
|
|
/* use for converting to BMesh which doesn't store bevel weight and edge crease by default */
|
|
|
|
char cd_flag;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-07-02 20:21:19 +02:00
|
|
|
short tangent_mask; /* which tangent layers are calculated */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Calculate vert and face normals */
|
2011-11-13 15:13:59 +00:00
|
|
|
void (*calcNormals)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2017-08-11 16:51:19 +02:00
|
|
|
/** Loop tessellation cache (WARNING! Only call inside threading-protected code!) */
|
2015-07-17 03:36:03 +10:00
|
|
|
void (*recalcLoopTri)(DerivedMesh *dm);
|
|
|
|
/** accessor functions */
|
|
|
|
const struct MLoopTri *(*getLoopTriArray)(DerivedMesh *dm);
|
|
|
|
int (*getNumLoopTri)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2011-11-13 15:13:59 +00:00
|
|
|
/* Misc. Queries */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
/* Also called in Editmode */
|
2005-03-27 21:27:12 +00:00
|
|
|
int (*getNumVerts)(DerivedMesh *dm);
|
2006-08-28 01:12:36 +00:00
|
|
|
int (*getNumEdges)(DerivedMesh *dm);
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
int (*getNumTessFaces)(DerivedMesh *dm);
|
2011-11-30 18:03:56 +00:00
|
|
|
int (*getNumLoops)(DerivedMesh *dm);
|
2011-11-29 13:01:51 +00:00
|
|
|
int (*getNumPolys)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Copy a single vert/edge/tessellated face from the derived mesh into
|
2015-08-01 12:36:14 +10:00
|
|
|
* ``*r_{vert/edge/face}``. note that the current implementation
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
* of this function can be quite slow, iterating over all
|
2009-01-04 18:16:34 +00:00
|
|
|
* elements (editmesh)
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*getVert)(DerivedMesh *dm, int index, struct MVert *r_vert);
|
|
|
|
void (*getEdge)(DerivedMesh *dm, int index, struct MEdge *r_edge);
|
|
|
|
void (*getTessFace)(DerivedMesh *dm, int index, struct MFace *r_face);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Return a pointer to the entire array of verts/edges/face from the
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
* derived mesh. if such an array does not exist yet, it will be created,
|
|
|
|
* and freed on the next ->release(). consider using getVert/Edge/Face if
|
|
|
|
* you are only interested in a few verts/edges/faces.
|
|
|
|
*/
|
2012-05-12 20:39:39 +00:00
|
|
|
struct MVert *(*getVertArray)(DerivedMesh *dm);
|
|
|
|
struct MEdge *(*getEdgeArray)(DerivedMesh *dm);
|
|
|
|
struct MFace *(*getTessFaceArray)(DerivedMesh *dm);
|
|
|
|
struct MLoop *(*getLoopArray)(DerivedMesh *dm);
|
|
|
|
struct MPoly *(*getPolyArray)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Copy all verts/edges/faces from the derived mesh into
|
2006-08-28 01:12:36 +00:00
|
|
|
* *{vert/edge/face}_r (must point to a buffer large enough)
|
|
|
|
*/
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*copyVertArray)(DerivedMesh *dm, struct MVert *r_vert);
|
|
|
|
void (*copyEdgeArray)(DerivedMesh *dm, struct MEdge *r_edge);
|
|
|
|
void (*copyTessFaceArray)(DerivedMesh *dm, struct MFace *r_face);
|
|
|
|
void (*copyLoopArray)(DerivedMesh *dm, struct MLoop *r_loop);
|
|
|
|
void (*copyPolyArray)(DerivedMesh *dm, struct MPoly *r_poly);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Return a copy of all verts/edges/faces from the derived mesh
|
2006-08-28 01:12:36 +00:00
|
|
|
* it is the caller's responsibility to free the returned pointer
|
|
|
|
*/
|
2012-05-12 20:39:39 +00:00
|
|
|
struct MVert *(*dupVertArray)(DerivedMesh *dm);
|
|
|
|
struct MEdge *(*dupEdgeArray)(DerivedMesh *dm);
|
|
|
|
struct MFace *(*dupTessFaceArray)(DerivedMesh *dm);
|
|
|
|
struct MLoop *(*dupLoopArray)(DerivedMesh *dm);
|
|
|
|
struct MPoly *(*dupPolyArray)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Return a pointer to a single element of vert/edge/face custom data
|
2006-08-28 01:12:36 +00:00
|
|
|
* from the derived mesh (this gives a pointer to the actual data, not
|
|
|
|
* a copy)
|
|
|
|
*/
|
2013-03-29 06:25:22 +00:00
|
|
|
void *(*getVertData)(DerivedMesh *dm, int index, int type);
|
|
|
|
void *(*getEdgeData)(DerivedMesh *dm, int index, int type);
|
|
|
|
void *(*getTessFaceData)(DerivedMesh *dm, int index, int type);
|
|
|
|
void *(*getPolyData)(DerivedMesh *dm, int index, int type);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Return a pointer to the entire array of vert/edge/face custom data
|
2006-08-28 01:12:36 +00:00
|
|
|
* from the derived mesh (this gives a pointer to the actual data, not
|
|
|
|
* a copy)
|
|
|
|
*/
|
2013-03-29 06:25:22 +00:00
|
|
|
void *(*getVertDataArray)(DerivedMesh *dm, int type);
|
|
|
|
void *(*getEdgeDataArray)(DerivedMesh *dm, int type);
|
|
|
|
void *(*getTessFaceDataArray)(DerivedMesh *dm, int type);
|
2013-04-03 20:10:08 +00:00
|
|
|
void *(*getLoopDataArray)(DerivedMesh *dm, int type);
|
2013-03-29 06:25:22 +00:00
|
|
|
void *(*getPolyDataArray)(DerivedMesh *dm, int type);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Retrieves the base CustomData structures for
|
2020-09-07 15:57:12 +10:00
|
|
|
* verts/edges/tessfaces/loops/faces. */
|
2012-05-12 20:39:39 +00:00
|
|
|
CustomData *(*getVertDataLayout)(DerivedMesh *dm);
|
|
|
|
CustomData *(*getEdgeDataLayout)(DerivedMesh *dm);
|
|
|
|
CustomData *(*getTessFaceDataLayout)(DerivedMesh *dm);
|
|
|
|
CustomData *(*getLoopDataLayout)(DerivedMesh *dm);
|
|
|
|
CustomData *(*getPolyDataLayout)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Optional grid access for subsurf */
|
2009-11-25 13:11:44 +00:00
|
|
|
int (*getNumGrids)(DerivedMesh *dm);
|
|
|
|
int (*getGridSize)(DerivedMesh *dm);
|
2012-05-12 20:39:39 +00:00
|
|
|
struct CCGElem **(*getGridData)(DerivedMesh *dm);
|
|
|
|
int *(*getGridOffset)(DerivedMesh *dm);
|
2012-05-10 20:33:09 +00:00
|
|
|
void (*getGridKey)(DerivedMesh *dm, struct CCGKey *key);
|
2012-05-12 20:39:39 +00:00
|
|
|
DMFlagMat *(*getGridFlagMats)(DerivedMesh *dm);
|
|
|
|
unsigned int **(*getGridHidden)(DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Direct Access Operations
|
|
|
|
* - Can be undefined
|
|
|
|
* - Must be defined for modifiers that only deform however */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Get vertex location, undefined if index is not valid */
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*getVertCo)(DerivedMesh *dm, int index, float r_co[3]);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Get smooth vertex normal, undefined if index is not valid */
|
2014-03-16 03:24:05 +11:00
|
|
|
void (*getVertNo)(DerivedMesh *dm, int index, float r_no[3]);
|
|
|
|
void (*getPolyNo)(DerivedMesh *dm, int index, float r_no[3]);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Get a map of vertices to faces
|
2012-02-05 06:20:51 +00:00
|
|
|
*/
|
2012-03-17 04:41:36 +00:00
|
|
|
const struct MeshElemMap *(*getPolyMap)(struct Object *ob, DerivedMesh *dm);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-06-27 17:48:39 +00:00
|
|
|
/** Release reference to the DerivedMesh. This function decides internally
|
Added custom vertex/edge/face data for meshes:
All data layers, including MVert/MEdge/MFace, are now managed as custom
data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are
still used of course, but allocating, copying or freeing these arrays
should be done through the CustomData API.
Work in progress documentation on this is here:
http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
Replaced TFace by MTFace:
This is the same struct, except that it does not contain color, that now
always stays separated in MCol. This was not a good design decision to
begin with, and it is needed for adding multiple color layers later. Note
that this does mean older Blender versions will not be able to read UV
coordinates from the next release, due to an SDNA limitation.
Removed DispListMesh:
This now fully replaced by DerivedMesh. To provide access to arrays of
vertices, edges and faces, like DispListMesh does. The semantics of the
DerivedMesh.getVertArray() and similar functions were changed to return
a pointer to an array if one exists, or otherwise allocate a temporary
one. On releasing the DerivedMesh, this temporary array will be removed
automatically.
Removed ssDM and meshDM DerivedMesh backends:
The ssDM backend was for DispListMesh, so that became obsolete automatically.
The meshDM backend was replaced by the custom data backend, that now figures
out which layers need to be modified, and only duplicates those.
This changes code in many places, and overall removes 2514 lines of code.
So, there's a good chance this might break some stuff, although I've been
testing it for a few days now. The good news is, adding multiple color and
uv layers should now become easy.
2006-11-20 04:28:02 +00:00
|
|
|
* if the DerivedMesh will be freed, or cached for later use. */
|
2005-03-27 20:34:18 +00:00
|
|
|
void (*release)(DerivedMesh *dm);
|
|
|
|
};
|
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
void DM_init_funcs(DerivedMesh *dm);
|
|
|
|
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_init(DerivedMesh *dm,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
2020-09-04 20:59:13 +02:00
|
|
|
int numTessFaces,
|
2015-07-02 16:20:22 +10:00
|
|
|
int numLoops,
|
|
|
|
int numPolys);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-09-23 22:57:00 +10:00
|
|
|
void DM_from_template_ex(DerivedMesh *dm,
|
|
|
|
DerivedMesh *source,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
|
|
|
int numTessFaces,
|
|
|
|
int numLoops,
|
|
|
|
int numPolys,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
const struct CustomData_MeshMasks *mask);
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_from_template(DerivedMesh *dm,
|
|
|
|
DerivedMesh *source,
|
|
|
|
DerivedMeshType type,
|
|
|
|
int numVerts,
|
|
|
|
int numEdges,
|
2020-09-04 20:59:13 +02:00
|
|
|
int numTessFaces,
|
2015-07-02 16:20:22 +10:00
|
|
|
int numLoops,
|
|
|
|
int numPolys);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
2019-11-25 01:14:39 +11:00
|
|
|
/**
|
|
|
|
* Utility function to release a DerivedMesh's layers
|
2020-09-02 19:10:18 +02:00
|
|
|
* returns true if DerivedMesh has to be released by the backend, false otherwise.
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2020-09-02 19:10:18 +02:00
|
|
|
bool DM_release(DerivedMesh *dm);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
void DM_set_only_copy(DerivedMesh *dm, const struct CustomData_MeshMasks *mask);
|
2006-12-05 17:42:03 +00:00
|
|
|
|
2006-08-28 01:12:36 +00:00
|
|
|
/* adds a vertex/edge/face custom data layer to a DerivedMesh, optionally
|
|
|
|
* backed by an external data array
|
2006-12-12 21:29:09 +00:00
|
|
|
* alloctype defines how the layer is allocated or copied, and how it is
|
|
|
|
* freed, see BKE_customdata.h for the different options
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2018-05-30 10:28:24 +02:00
|
|
|
void DM_add_vert_layer(struct DerivedMesh *dm, int type, eCDAllocType alloctype, void *layer);
|
|
|
|
void DM_add_edge_layer(struct DerivedMesh *dm, int type, eCDAllocType alloctype, void *layer);
|
|
|
|
void DM_add_tessface_layer(struct DerivedMesh *dm, int type, eCDAllocType alloctype, void *layer);
|
|
|
|
void DM_add_loop_layer(DerivedMesh *dm, int type, eCDAllocType alloctype, void *layer);
|
|
|
|
void DM_add_poly_layer(struct DerivedMesh *dm, int type, eCDAllocType alloctype, void *layer);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
/* custom data access functions
|
|
|
|
* return pointer to data from first layer which matches type
|
|
|
|
* if they return NULL for valid indices, data doesn't exist
|
|
|
|
* note these return pointers - any change modifies the internals of the mesh
|
|
|
|
*/
|
|
|
|
void *DM_get_vert_data(struct DerivedMesh *dm, int index, int type);
|
|
|
|
void *DM_get_edge_data(struct DerivedMesh *dm, int index, int type);
|
2011-11-29 05:09:54 +00:00
|
|
|
void *DM_get_tessface_data(struct DerivedMesh *dm, int index, int type);
|
2012-10-30 19:20:17 +00:00
|
|
|
void *DM_get_poly_data(struct DerivedMesh *dm, int index, int type);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
/* custom data layer access functions
|
|
|
|
* return pointer to first data layer which matches type (a flat array)
|
|
|
|
* if they return NULL, data doesn't exist
|
|
|
|
* note these return pointers - any change modifies the internals of the mesh
|
|
|
|
*/
|
|
|
|
void *DM_get_vert_data_layer(struct DerivedMesh *dm, int type);
|
|
|
|
void *DM_get_edge_data_layer(struct DerivedMesh *dm, int type);
|
2009-08-15 17:31:28 +00:00
|
|
|
void *DM_get_tessface_data_layer(struct DerivedMesh *dm, int type);
|
2011-11-29 05:09:54 +00:00
|
|
|
void *DM_get_poly_data_layer(struct DerivedMesh *dm, int type);
|
2012-02-05 11:30:26 +00:00
|
|
|
void *DM_get_loop_data_layer(struct DerivedMesh *dm, int type);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
|
|
|
/* custom data copy functions
|
|
|
|
* copy count elements from source_index in source to dest_index in dest
|
2006-12-05 17:42:03 +00:00
|
|
|
* these copy all layers for which the CD_FLAG_NOCOPY flag is not set
|
2006-08-28 01:12:36 +00:00
|
|
|
*/
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_copy_vert_data(struct DerivedMesh *source,
|
|
|
|
struct DerivedMesh *dest,
|
|
|
|
int source_index,
|
|
|
|
int dest_index,
|
|
|
|
int count);
|
2006-08-28 01:12:36 +00:00
|
|
|
|
(NOTE: DO NOT TEST)
Start of planned DerivedMesh refactoring. The mface
interfaces in DerivedMesh have been renamed to reflect
their new status as tesselated face interfaces (rather
then the primary ones, which are now stored in mpolys).
short review: mpolys store "primary" face data, while
mfaces store the tesselated form of the mesh (generally
as triangles). mpolys are defined by mloops, and each
mpoly defines a range of loops it "owns" in the main
mloop array.
I've also added basic read-only face iterators, which
are implemented for CDDM, ccgsubsurf, and the bmeditmesh
derivedmesh. Since faces are now variable-length things,
trying to implement the same interface as mfaces would not
have worked well (especially since faces are stored as
an mpoly + a range of mloops).
I figure first we can evaluate these simple read-only
face iterators, then decide if a) we like using iterators
in DerivedMesh, b) how much of it should use them, and c)
if we want write-capable iterators.
I plan to write official docs on this design after I get
it more stable; I'm committing now because there's a rather
lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
|
|
|
/*sets up mpolys for a DM based on face iterators in source*/
|
|
|
|
void DM_DupPolys(DerivedMesh *source, DerivedMesh *target);
|
|
|
|
|
2013-05-30 17:36:43 +00:00
|
|
|
void DM_ensure_normals(DerivedMesh *dm);
|
2012-01-05 12:40:09 +00:00
|
|
|
|
2015-07-17 03:36:03 +10:00
|
|
|
void DM_ensure_looptri_data(DerivedMesh *dm);
|
2014-07-21 12:02:05 +02:00
|
|
|
|
2015-07-02 16:20:22 +10:00
|
|
|
void DM_interp_vert_data(struct DerivedMesh *source,
|
|
|
|
struct DerivedMesh *dest,
|
|
|
|
int *src_indices,
|
|
|
|
float *weights,
|
|
|
|
int count,
|
|
|
|
int dest_index);
|
|
|
|
|
2018-10-17 12:43:41 +02:00
|
|
|
void mesh_get_mapped_verts_coords(struct Mesh *me_eval, float (*r_cos)[3], const int totcos);
|
2005-03-29 16:43:39 +00:00
|
|
|
|
2012-05-12 20:39:39 +00:00
|
|
|
/* same as above but wont use render settings */
|
2018-10-09 16:52:46 +11:00
|
|
|
struct Mesh *editbmesh_get_eval_cage(struct Depsgraph *depsgraph,
|
2018-04-06 12:07:27 +02:00
|
|
|
struct Scene *scene,
|
|
|
|
struct Object *,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
struct BMEditMesh *em,
|
|
|
|
const struct CustomData_MeshMasks *dataMask);
|
2018-12-06 09:38:08 +11:00
|
|
|
struct Mesh *editbmesh_get_eval_cage_from_orig(struct Depsgraph *depsgraph,
|
|
|
|
struct Scene *scene,
|
2020-09-04 20:59:13 +02:00
|
|
|
struct Object *obedit,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
const struct CustomData_MeshMasks *dataMask);
|
2018-10-09 16:52:46 +11:00
|
|
|
struct Mesh *editbmesh_get_eval_cage_and_final(struct Depsgraph *depsgraph,
|
2018-04-06 12:07:27 +02:00
|
|
|
struct Scene *scene,
|
|
|
|
struct Object *,
|
Refactor CDData masks, to have one mask per mesh elem type.
We already have different storages for cddata of verts, edges etc.,
'simply' do the same for the mask flags we use all around Blender code
to request some data, or limit some operation to some layers, etc.
Reason we need this is that some cddata types (like Normals) are
actually shared between verts/polys/loops, and we don’t want to generate
clnors everytime we request vnors!
As a side note, this also does final fix to T59338, which was the
trigger for this patch (need to request computed loop normals for
another mesh than evaluated one).
Reviewers: brecht, campbellbarton, sergey
Differential Revision: https://developer.blender.org/D4407
2019-03-07 11:13:40 +01:00
|
|
|
struct BMEditMesh *em,
|
|
|
|
const struct CustomData_MeshMasks *dataMask,
|
2018-10-09 16:52:46 +11:00
|
|
|
struct Mesh **r_final);
|
2014-08-01 15:42:17 +02:00
|
|
|
|
2019-08-22 06:28:35 +10:00
|
|
|
float (*editbmesh_vert_coords_alloc(struct BMEditMesh *em, int *r_vert_len))[3];
|
2018-10-09 15:04:51 +11:00
|
|
|
bool editbmesh_modifier_is_enabled(struct Scene *scene,
|
2020-10-26 17:07:58 +11:00
|
|
|
const struct Object *ob,
|
2018-10-09 15:04:51 +11:00
|
|
|
struct ModifierData *md,
|
|
|
|
bool has_prev_mesh);
|
2018-04-06 12:07:27 +02:00
|
|
|
void makeDerivedMesh(struct Depsgraph *depsgraph,
|
|
|
|
struct Scene *scene,
|
|
|
|
struct Object *ob,
|
|
|
|
struct BMEditMesh *em,
|
2019-03-27 19:07:16 +01:00
|
|
|
const struct CustomData_MeshMasks *dataMask);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2016-04-26 18:43:02 +10:00
|
|
|
void DM_calc_loop_tangents(DerivedMesh *dm,
|
|
|
|
bool calc_active_tangent,
|
|
|
|
const char (*tangent_names)[MAX_NAME],
|
2020-09-04 20:59:13 +02:00
|
|
|
int tangent_names_len);
|
2017-05-24 22:33:21 +10:00
|
|
|
|
2012-01-19 00:18:25 +00:00
|
|
|
/* debug only */
|
|
|
|
#ifndef NDEBUG
|
|
|
|
char *DM_debug_info(DerivedMesh *dm);
|
|
|
|
void DM_debug_print(DerivedMesh *dm);
|
2013-09-04 01:29:34 +00:00
|
|
|
|
|
|
|
bool DM_is_valid(DerivedMesh *dm);
|
2005-03-27 20:34:18 +00:00
|
|
|
#endif
|
|
|
|
|
2020-03-02 15:07:49 +01:00
|
|
|
#ifdef __cplusplus
|
|
|
|
}
|
|
|
|
#endif
|