archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity
This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
4e86b48cbdcbe1d0177b57dba74e08ba21e1878b
blender-archive/source/blender/blenkernel/BKE_DerivedMesh.h

653 lines
25 KiB
C++
Raw Normal View History

doxygen: blenkernel under core as module.
2011-02-18 13:05:18 +00:00
/*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
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
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* of the License, or (at your option) any later version.
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
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,
correct fsf address
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
*
* The Original Code is Copyright (C) 2001-2002 by NaN Holding BV.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-16 22:40:48 +00:00
* ***** END GPL LICENSE BLOCK *****
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
*/
#ifndef BKE_DERIVEDMESH_H
#define BKE_DERIVEDMESH_H
another attempt to hopefully fix gcc compiling
2009-07-17 01:57:12 +00:00
/*
Basic design of the DerivedMesh system:
DerivedMesh is a common set of interfaces for mesh systems.
There are three main mesh data structures in Blender: Mesh, CDDM, and BMesh.
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
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).
Mesh is the "serialized" structure, used for storing object-mode mesh data
and also for saving stuff to disk. It's interfaces are also what DerivedMesh
uses to communicate with.
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.
*/
/*
* Note: This sturcture is read-only, for all practical purposes.
* 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.
*/
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 05:58:43 +00:00
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 16:38:37 +00:00
#include "DNA_customdata_types.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"
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 17:42:03 +00:00
#include "BKE_customdata.h"
merge with 2.5 at r20307. note there were some python hacking necassary for this to work, so um hopefully there's not too much cruft from that. [[Split portion of a mixed commit.]]
2009-05-23 03:24:15 +00:00
#include "BKE_bvhutils.h"
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
- convert mesh_modifier to return deformed verts instead of leaving in a DL_VERTS type displist (and modifying mesh) - removed DL_VERTS displist type (woot woot) - makeDispListMesh now puts deformed verts in object->derivedDeform - switch over other system parts to new deformed vert storage, still kinda hacky and maybe some inconsistencies... will be sorted out soon enough. - moved build_particle_system to makeDispListMesh... this may have adverse side effects, needs to be sorted out with depgraph system
2005-07-17 17:41:03 +00:00
struct MVert;
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
struct MEdge;
struct MFace;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
struct MTFace;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
struct Object;
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
struct Scene;
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
struct Mesh;
renamed BMTessMesh to BMEditMesh, did some more monkeywork, cleaned up the more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
2009-05-18 08:46:04 +00:00
struct BMEditMesh;
* New option on modifiers that don't change topology: Apply as Shape Rather than applying the modifier to the object data, it will create a new shape with the deformed vertices in there. Only mesh at the moment, other object types on the todo.
2009-11-22 13:44:09 +00:00
struct KeyBlock;
- added apply button for individual modifiers
2005-07-26 00:45:19 +00:00
struct ModifierData;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
struct MCol;
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 13:56:07 +00:00
struct ColorBand;
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 20:51:28 +00:00
struct GPUVertexAttribs;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
struct GPUDrawObject;
renamed BMTessMesh to BMEditMesh, did some more monkeywork, cleaned up the more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
2009-05-18 08:46:04 +00:00
struct BMEditMesh;
Moved the PBVH from sculpt session to DerivedMesh/CDDM. * Multires sculpting appears to work now * PBVH gets recalculated in some cases where it shouldn't, haven't looked into this yet
2009-10-28 06:06:05 +00:00
struct ListBase;
struct PBVH;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* number of sub-elements each mesh element has (for interpolation) */
#define SUB_ELEMS_VERT 0
#define SUB_ELEMS_EDGE 2
further fixes for modifiers, and edge loop select works now.
2009-06-16 20:08:40 +00:00
#define SUB_ELEMS_FACE 50
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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
/*
Shift-G (select similar) is now bmeshafied for edge select mode. The patch was by Wael El Oraiby. Commit of patch #19257.
2009-08-28 09:36:31 +00:00
Note: all mface interfaces now officially operate on tesselated data.
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
*/
Sculpt: Subsurf * Now uses the CCG DerivedMesh also in object mode, used to be edit mode only. * Create CD_ORIGINDEX layer on demand, to save memory. * Removed ss_to_cdderivedmesh function, and instead create ccgdm and then convert that to cddm, to avoid code duplication. * Added and implement DerivedMesh interface functions to obtain face grids. * Store edge/face flags more memory efficient. * Export CCGDerivedMesh struct in BKE_subsurf.h
2009-11-25 13:11:44 +00:00
typedef struct DMGridData {
float co[3];
float no[3];
} DMGridData;
typedef struct DMGridAdjacency {
int index[4];
int rotation[4];
} DMGridAdjacency;
Fix #20519: shrinkwrap modifier doesnt work with subsurface modifier. Fix #20516: subsurf modiefier+pressing add for smoke sims results in crash. Fix retopo not working correct on subsurf mesh. Various deforming modifiers were not correctly taking into account that a derivedmesh is not necessarily a CDDerivedMesh, made utility functions for this now.
2010-01-06 12:05:46 +00:00
typedef enum DerivedMeshType {
DM_TYPE_CDDM,
merge with trunk/2.5 at r25907
2010-01-13 07:26:11 +00:00
DM_TYPE_EDITBMESH,
Fix #20519: shrinkwrap modifier doesnt work with subsurface modifier. Fix #20516: subsurf modiefier+pressing add for smoke sims results in crash. Fix retopo not working correct on subsurf mesh. Various deforming modifiers were not correctly taking into account that a derivedmesh is not necessarily a CDDerivedMesh, made utility functions for this now.
2010-01-06 12:05:46 +00:00
DM_TYPE_CCGDM
} DerivedMeshType;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
typedef struct DerivedMesh DerivedMesh;
struct DerivedMesh {
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
/* 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;
int numVertData, numEdgeData, numFaceData, 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 */
merge with 2.5 at r20307. note there were some python hacking necassary for this to work, so um hopefully there's not too much cruft from that. [[Split portion of a mixed commit.]]
2009-05-23 03:24:15 +00:00
BVHCache bvhCache;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
struct GPUDrawObject *drawObject;
Fix #20519: shrinkwrap modifier doesnt work with subsurface modifier. Fix #20516: subsurf modiefier+pressing add for smoke sims results in crash. Fix retopo not working correct on subsurf mesh. Various deforming modifiers were not correctly taking into account that a derivedmesh is not necessarily a CDDerivedMesh, made utility functions for this now.
2010-01-06 12:05:46 +00:00
DerivedMeshType type;
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
/* calculate vert and face normals */
void (*calcNormals)(DerivedMesh *dm);
/* recalculates mesh tesselation */
(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
void (*recalcTesselation)(DerivedMesh *dm);
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 21:27:12 +00:00
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
/* Misc. Queries */
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Also called in Editmode */
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 21:27:12 +00:00
int (*getNumVerts)(DerivedMesh *dm);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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);
int (*getNumFaces) (DerivedMesh *dm);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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
/* copy a single vert/edge/tesselated face from the derived mesh into
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
* *{vert/edge/face}_r. note that the current implementation
* of this function can be quite slow, iterating over all
2.5 / Cleanup - remove Verse support. This will be brought back in The Future (probably jiri + me) This means 5k lines less in blenkernel. - fix two small errors for global cleanup, now compiles properly with FFMPEG enabled too.
2009-01-04 18:16:34 +00:00
* elements (editmesh)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
*/
void (*getVert)(DerivedMesh *dm, int index, struct MVert *vert_r);
void (*getEdge)(DerivedMesh *dm, int index, struct MEdge *edge_r);
(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
void (*getTessFace)(DerivedMesh *dm, int index, struct MFace *face_r);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* return a pointer to the entire array of verts/edges/face from the
* 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.
*/
struct MVert *(*getVertArray)(DerivedMesh *dm);
struct MEdge *(*getEdgeArray)(DerivedMesh *dm);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
struct MFace *(*getTessFaceArray)(DerivedMesh *dm);
=bmesh= Removed the DerivedMesh face iterators (they sucked). This should make subsurf faster. Also sped up multires a bit (not sure if it's strictly correct, need to look at it later).
2011-06-14 03:16:08 +00:00
struct MLoop *(*getLoopArray)(DerivedMesh *dm);
struct MPoly *(*getPolyArray)(DerivedMesh *dm);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* copy all verts/edges/faces from the derived mesh into
* *{vert/edge/face}_r (must point to a buffer large enough)
*/
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
void (*copyVertArray)(DerivedMesh *dm, struct MVert *vert_r);
void (*copyEdgeArray)(DerivedMesh *dm, struct MEdge *edge_r);
(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
void (*copyTessFaceArray)(DerivedMesh *dm, struct MFace *face_r);
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
void (*copyLoopArray)(DerivedMesh *dm, struct MLoop *loop_r);
void (*copyPolyArray)(DerivedMesh *dm, struct MPoly *poly_r);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* return a copy of all verts/edges/faces from the derived mesh
* it is the caller's responsibility to free the returned pointer
*/
struct MVert *(*dupVertArray)(DerivedMesh *dm);
struct MEdge *(*dupEdgeArray)(DerivedMesh *dm);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
struct MFace *(*dupTessFaceArray)(DerivedMesh *dm);
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
struct MLoop *(*dupLoopArray)(DerivedMesh *dm);
struct MPoly *(*dupPolyArray)(DerivedMesh *dm);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* return a pointer to a single element of vert/edge/face custom data
* from the derived mesh (this gives a pointer to the actual data, not
* a copy)
*/
void *(*getVertData)(DerivedMesh *dm, int index, int type);
void *(*getEdgeData)(DerivedMesh *dm, int index, int type);
(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
void *(*getTessFaceData)(DerivedMesh *dm, int index, int type);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* return a pointer to the entire array of vert/edge/face custom data
* from the derived mesh (this gives a pointer to the actual data, not
* a copy)
*/
void *(*getVertDataArray)(DerivedMesh *dm, int type);
void *(*getEdgeDataArray)(DerivedMesh *dm, int type);
(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
void *(*getTessFaceDataArray)(DerivedMesh *dm, int type);
Array modifier is now implemented using bmesh (though it's not completely feature-complete yet). I ported over the remove doubles code from the old bmesh branch for this, and split it into two bmops, "Weld Verts" and "Remove Doubles". Weld verts welds specific verts together, while remove doubles finds doubles and welds them. I also reverted the hotkey change I made earlier.
2009-06-23 05:35:49 +00:00
/*retrieves the base CustomData structures for
verts/edges/tessfaces/loops/facdes*/
CustomData *(*getVertDataLayout)(DerivedMesh *dm);
CustomData *(*getEdgeDataLayout)(DerivedMesh *dm);
CustomData *(*getTessFaceDataLayout)(DerivedMesh *dm);
CustomData *(*getLoopDataLayout)(DerivedMesh *dm);
CustomData *(*getFaceDataLayout)(DerivedMesh *dm);
/*copies all customdata for an element source into dst at index dest*/
void (*copyFromVertCData)(DerivedMesh *dm, int source, CustomData *dst, int dest);
void (*copyFromEdgeCData)(DerivedMesh *dm, int source, CustomData *dst, int dest);
void (*copyFromFaceCData)(DerivedMesh *dm, int source, CustomData *dst, int dest);
made the crash handler disabled by a command line flag, insted of being #ifdef'd out on release builds. also did little bit of work on subsurf. and face select can now deselect again, and fixed some other bugs with it (and subsurf).
2009-08-15 17:31:28 +00:00
Sculpt: Subsurf * Now uses the CCG DerivedMesh also in object mode, used to be edit mode only. * Create CD_ORIGINDEX layer on demand, to save memory. * Removed ss_to_cdderivedmesh function, and instead create ccgdm and then convert that to cddm, to avoid code duplication. * Added and implement DerivedMesh interface functions to obtain face grids. * Store edge/face flags more memory efficient. * Export CCGDerivedMesh struct in BKE_subsurf.h
2009-11-25 13:11:44 +00:00
/* optional grid access for subsurf */
int (*getNumGrids)(DerivedMesh *dm);
int (*getGridSize)(DerivedMesh *dm);
DMGridData **(*getGridData)(DerivedMesh *dm);
DMGridAdjacency *(*getGridAdjacency)(DerivedMesh *dm);
Sculpt Branch: * Multithread parts of multires and subsurf. Only loops working on face grid data and do no memory allocation have been multithreaded, others would be more complicated. * Force some CCGSubsurf functions to be inlined, gives a small overall speedup in subsurf code. * Fix sculpting not working correct with transformed objects. * Fix a few cases of "spikes" on lower level multires levels. There's still cases where it happens, usually on boundary cornders. The problem is that in such cases the limit surfaces can be very different from the low res surface, so the tangent space is very different too.. * Fix crash deleting multires higher levels with level set to 0. * Fix crashes that happened sometimes when adding faces in editmode.
2009-12-03 18:35:37 +00:00
int *(*getGridOffset)(DerivedMesh *dm);
Sculpt: Subsurf * Now uses the CCG DerivedMesh also in object mode, used to be edit mode only. * Create CD_ORIGINDEX layer on demand, to save memory. * Removed ss_to_cdderivedmesh function, and instead create ccgdm and then convert that to cddm, to avoid code duplication. * Added and implement DerivedMesh interface functions to obtain face grids. * Store edge/face flags more memory efficient. * Export CCGDerivedMesh struct in BKE_subsurf.h
2009-11-25 13:11:44 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Iterate over each mapped vertex in the derived mesh, calling the
* given function with the original vert and the mapped vert's new
* coordinate and normal. For historical reasons the normal can be
* passed as a float or short array, only one should be non-NULL.
*/
void (*foreachMappedVert)(
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
DerivedMesh *dm,
void (*func)(void *userData, int index, float *co,
float *no_f, short *no_s),
void *userData);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Iterate over each mapped edge in the derived mesh, calling the
* given function with the original edge and the mapped edge's new
* coordinates.
*/
void (*foreachMappedEdge)(DerivedMesh *dm,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
void (*func)(void *userData, int index,
float *v0co, float *v1co),
void *userData);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Iterate over each mapped face in the derived mesh, calling the
* given function with the original face and the mapped face's (or
* faces') center and normal.
*/
void (*foreachMappedFaceCenter)(DerivedMesh *dm,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
void (*func)(void *userData, int index,
float *cent, float *no),
void *userData);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Iterate over all vertex points, calling DO_MINMAX with given args.
*
* Also called in Editmode
*/
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 04:17:33 +00:00
void (*getMinMax)(DerivedMesh *dm, float min_r[3], float max_r[3]);
- added DirectMesh.getVert{Co,No} functions - added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 01:18:59 +00:00
/* Direct Access Operations */
/* o Can be undefined */
/* o Must be defined for modifiers that only deform however */
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Get vertex location, undefined if index is not valid */
- added DirectMesh.getVert{Co,No} functions - added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 01:18:59 +00:00
void (*getVertCo)(DerivedMesh *dm, int index, float co_r[3]);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Fill the array (of length .getNumVerts()) with all vertex locations */
- added DerivedMesh.getVertCos function and implementations - added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-18 19:58:23 +00:00
void (*getVertCos)(DerivedMesh *dm, float (*cos_r)[3]);
Fix/change in normal computation, now the viewport uses the same angle weighted normals as the render engine, and the render engine will copy normals from the mesh rather than always recalculating them. Subsurf/multires still use regular vertex normals, but they are expected to be sufficiently high resolution to not need this. This means that normal maps displayed in the viewport actually match the render engine exactly and don't have artifacts due to this discrepancy. It of course also avoids unexpected surprises where your render normals look different than your viewport normals. Subversion bumped to 4 for version patch to recalculate normals. Patch by Morten Mikkelsen, with some small changes.
2011-03-20 13:35:35 +00:00
/* Get smooth vertex normal, undefined if index is not valid */
- added DirectMesh.getVert{Co,No} functions - added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 01:18:59 +00:00
void (*getVertNo)(DerivedMesh *dm, int index, float no_r[3]);
Moved the PBVH from sculpt session to DerivedMesh/CDDM. * Multires sculpting appears to work now * PBVH gets recalculated in some cases where it shouldn't, haven't looked into this yet
2009-10-28 06:06:05 +00:00
/* Get a map of vertices to faces
*/
Sculpt: * Fix #20482: grab brush + size pressure sensitivity don't work together, disabled the pressure sensitivty for that case now. * Fix for smooth brush messing up mesh sometimes, smooth factor is now clamped to reasonable range. * Fix #20449: smooth brush + mirror modifier could crash.
2010-01-04 16:53:32 +00:00
struct ListBase *(*getFaceMap)(struct Object *ob, DerivedMesh *dm);
Moved the PBVH from sculpt session to DerivedMesh/CDDM. * Multires sculpting appears to work now * PBVH gets recalculated in some cases where it shouldn't, haven't looked into this yet
2009-10-28 06:06:05 +00:00
/* Get the BVH used for paint modes
*/
Sculpt: Subsurf * Now uses the CCG DerivedMesh also in object mode, used to be edit mode only. * Create CD_ORIGINDEX layer on demand, to save memory. * Removed ss_to_cdderivedmesh function, and instead create ccgdm and then convert that to cddm, to avoid code duplication. * Added and implement DerivedMesh interface functions to obtain face grids. * Store edge/face flags more memory efficient. * Export CCGDerivedMesh struct in BKE_subsurf.h
2009-11-25 13:11:44 +00:00
struct PBVH *(*getPBVH)(struct Object *ob, DerivedMesh *dm);
Moved the PBVH from sculpt session to DerivedMesh/CDDM. * Multires sculpting appears to work now * PBVH gets recalculated in some cases where it shouldn't, haven't looked into this yet
2009-10-28 06:06:05 +00:00
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
/* Drawing Operations */
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw all vertices as bgl points (no options) */
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
void (*drawVerts)(DerivedMesh *dm);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw edges in the UV mesh (if exists) */
- added DerivedMesh.drawUVEdges function & implementations - removed DerivedMesh.drawLooseEdges and replaced with much more general drawEdgesFlag function that draws based edge flags. - switch DerivedMesh.drawFacesTex to give user control over which faces are drawn - added object_uvs_changed and object_tface_flags_changed functions to do object recalc flag flush/redraw queueing and added calls in appropriate places - added various edge flags to mark TFace information. This is used by the drawEdgesFlag routine and was the best way I could come up with to deal with drawing TFace information from modifier stack. Unfortunate side effects are (1) uses a lot of MEdge flags (although not needed in file so thats fine) and (2) requires recalculation of modifier stack on UV selection changes. #2 is disappointing but I could not find a better solution. - update UV mesh shadow drawing to use modifier result. At the moment just uses the final result but probably should be integrated with the editmode cage option. - convert draw_tfaces3D to use drawEdgesFlag routine which cleaned up the code quite a bit. - convert draw_tface_mesh to draw using result of modifier stack. Same comment about which result actually gets draw in FACESELECT mode as for UV editor shadow drawing applies. There is a still a bug in that selection is using the wrong mesh to draw.
2005-08-18 11:31:20 +00:00
void (*drawUVEdges)(DerivedMesh *dm);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw all edges as lines (no options)
*
* Also called for *final* editmode DerivedMeshes
*/
Sculpt Mode Bugfixes: * #20833: layer brush doesn't work with multires. * #20946: sculpt mode partially removes parts of the mesh in the viewport. * #20420: grab brush stops after moving some distance. * #20906: sculpt grab tool moves in wrong direction. * #21132 and #21272: undo on object with subdivision surface modifier crashes. * #21115: subsurf + multires + sculpting + undo causes crash. * #20683: sculpt + multires apply + undo crash. * #19094: wrong outline in solid mode.
2010-03-22 11:59:36 +00:00
void (*drawEdges)(DerivedMesh *dm, int drawLooseEdges, int drawAllEdges);
- added DerivedMesh.drawUVEdges function & implementations - removed DerivedMesh.drawLooseEdges and replaced with much more general drawEdgesFlag function that draws based edge flags. - switch DerivedMesh.drawFacesTex to give user control over which faces are drawn - added object_uvs_changed and object_tface_flags_changed functions to do object recalc flag flush/redraw queueing and added calls in appropriate places - added various edge flags to mark TFace information. This is used by the drawEdgesFlag routine and was the best way I could come up with to deal with drawing TFace information from modifier stack. Unfortunate side effects are (1) uses a lot of MEdge flags (although not needed in file so thats fine) and (2) requires recalculation of modifier stack on UV selection changes. #2 is disappointing but I could not find a better solution. - update UV mesh shadow drawing to use modifier result. At the moment just uses the final result but probably should be integrated with the editmode cage option. - convert draw_tfaces3D to use drawEdgesFlag routine which cleaned up the code quite a bit. - convert draw_tface_mesh to draw using result of modifier stack. Same comment about which result actually gets draw in FACESELECT mode as for UV editor shadow drawing applies. There is a still a bug in that selection is using the wrong mesh to draw.
2005-08-18 11:31:20 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw all loose edges (edges w/ no adjoining faces) */
- sillyness... added drawMappedEdges for mesh - revert to drawLooseEdges instead of general drawEdgesFlag - ditched TFace edge flags, done dynamically now which also means don't need to recalc surface on flag changes - added BLI_edgehash, guess what it does
2005-08-21 20:48:45 +00:00
void (*drawLooseEdges)(DerivedMesh *dm);
- added DerivedMesh.drawUVEdges function & implementations - removed DerivedMesh.drawLooseEdges and replaced with much more general drawEdgesFlag function that draws based edge flags. - switch DerivedMesh.drawFacesTex to give user control over which faces are drawn - added object_uvs_changed and object_tface_flags_changed functions to do object recalc flag flush/redraw queueing and added calls in appropriate places - added various edge flags to mark TFace information. This is used by the drawEdgesFlag routine and was the best way I could come up with to deal with drawing TFace information from modifier stack. Unfortunate side effects are (1) uses a lot of MEdge flags (although not needed in file so thats fine) and (2) requires recalculation of modifier stack on UV selection changes. #2 is disappointing but I could not find a better solution. - update UV mesh shadow drawing to use modifier result. At the moment just uses the final result but probably should be integrated with the editmode cage option. - convert draw_tfaces3D to use drawEdgesFlag routine which cleaned up the code quite a bit. - convert draw_tface_mesh to draw using result of modifier stack. Same comment about which result actually gets draw in FACESELECT mode as for UV editor shadow drawing applies. There is a still a bug in that selection is using the wrong mesh to draw.
2005-08-18 11:31:20 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw all faces
* o Set face normal or vertex normal based on inherited face flag
* o Use inherited face material index to call setMaterial
* o Only if setMaterial returns true
*
* Also called for *final* editmode DerivedMeshes
*/
Moved the PBVH from sculpt session to DerivedMesh/CDDM. * Multires sculpting appears to work now * PBVH gets recalculated in some cases where it shouldn't, haven't looked into this yet
2009-10-28 06:06:05 +00:00
void (*drawFacesSolid)(DerivedMesh *dm, float (*partial_redraw_planes)[4],
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int fast, int (*setMaterial)(int, void *attribs));
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw all faces
* o If useTwoSided, draw front and back using col arrays
* o col1,col2 are arrays of length numFace*4 of 4 component colors
* in ABGR format, and should be passed as per-face vertex color.
*/
void (*drawFacesColored)(DerivedMesh *dm, int useTwoSided,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
unsigned char *col1, unsigned char *col2);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* Draw all faces using MTFace
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
* o Drawing options too complicated to enumerate, look at code.
*/
void (*drawFacesTex)(DerivedMesh *dm,
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
int (*setDrawOptions)(struct MTFace *tface,
uv texture (though not glsl) works now. also fixed some bugs. still some issues left, and for some reason textured objs aren't displaying properly in object mode.
2009-07-24 10:43:58 +00:00
int has_vcol, int matnr));
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
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 20:51:28 +00:00
/* Draw all faces with GLSL materials
* o setMaterial is called for every different material nr
* o Only if setMaterial returns true
*/
void (*drawFacesGLSL)(DerivedMesh *dm,
int (*setMaterial)(int, void *attribs));
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw mapped faces (no color, or texture)
* o Only if !setDrawOptions or
* setDrawOptions(userData, mapped-face-index, drawSmooth_r)
* returns true
*
* If drawSmooth is set to true then vertex normals should be set and
* glShadeModel called with GL_SMOOTH. Otherwise the face normal should
* be set and glShadeModel called with GL_FLAT.
*
* The setDrawOptions is allowed to not set drawSmooth (for example, when
* lighting is disabled), in which case the implementation should draw as
* smooth shaded.
*/
void (*drawMappedFaces)(DerivedMesh *dm,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int (*setDrawOptions)(void *userData, int index,
int *drawSmooth_r),
bugfix [#23506] Bevel Modifier display problem This is a more general problem that drawing functions would skip faces when the original index could not be found, screw result for example wasnt visible in editmode too. Fixed by adding a material set argument to DerivedMesh->drawMappedFaces(), this was already being done in some of the other drawing functions.
2010-10-05 11:25:34 +00:00
void *userData, int useColors,
Fix #28347: VBO's highlights wrong faces when Mirror modifier is in use Added callback to drawMappedFaces which checks if two faces have got equal draw options. After discussion with Brecht we found it's nicest solution for now: - Disabling VBOs in edit mode for this case wouldn't be nicer for this case - some additional flag stored in DM should be added in this case. - Adding new callback in DM isn't nicer that this solution. - Handling face selection in drawobject would lead to duplicated code which is also not nice. Hopefully, this callback could handle all cases in the future. Also, Brecht mentioned current VBO implementation isn't perfect, so maybe when we'll redesign this area dealing with edit mode wouldn't be so tricky.
2011-08-29 16:07:44 +00:00
int (*setMaterial)(int, void *attribs),
int (*compareDrawOptions)(void *userData, int cur_index, int next_index));
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* Draw mapped faces using MTFace
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
* o Drawing options too complicated to enumerate, look at code.
*/
void (*drawMappedFacesTex)(DerivedMesh *dm,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int (*setDrawOptions)(void *userData,
int index),
void *userData);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
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 20:51:28 +00:00
/* Draw mapped faces with GLSL materials
* o setMaterial is called for every different material nr
* o setDrawOptions is called for every face
* o Only if setMaterial and setDrawOptions return true
*/
void (*drawMappedFacesGLSL)(DerivedMesh *dm,
int (*setMaterial)(int, void *attribs),
int (*setDrawOptions)(void *userData, int index), void *userData);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw mapped edges as lines
* o Only if !setDrawOptions or setDrawOptions(userData, mapped-edge)
* returns true
*/
void (*drawMappedEdges)(DerivedMesh *dm,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int (*setDrawOptions)(void *userData, int index),
void *userData);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* Draw mapped edges as lines with interpolation values
* o Only if !setDrawOptions or
* setDrawOptions(userData, mapped-edge, mapped-v0, mapped-v1, t)
* returns true
*
* NOTE: This routine is optional!
*/
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
void (*drawMappedEdgesInterp)(DerivedMesh *dm,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int (*setDrawOptions)(void *userData,
int index),
void (*setDrawInterpOptions)(void *userData,
int index,
float t),
void *userData);
- added drawMapped{Verts,Edges,Faces}EMSelect calls to DerivedMesh with implementations - updated drawobject selection code to use DerivedMesh (last DispListMesh usage in drawobject.c that needs to be replaced! Woot!) - interface could still be a lot cleaner, mostly calculating indices for the various things to pass to selection color routine is hacky.
2005-03-28 06:46:21 +00:00
Texturing: texture and 3d view draw type changes, these should only have any effect for a render engine using new shading nodes. In short: * No longer uses images assigned to faces in the uv layer, rather the active image texture node is what is edited/painted/drawn. * Textured draw type now shows the active image texture node, with solid lighting. * Material draw mode shows GLSL shader of a simplified material node tree, using solid lighting. * Textures for modifiers, brushes, etc, are now available from a dropdown in the texture tab in the properties editor. These do not use new shading nodes yet. http://wiki.blender.org/index.php/Dev:2.6/Source/Render/TextureWorkflow
2011-11-08 13:07:16 +00:00
/* Draw all faces with materials
* o setMaterial is called for every different material nr
* o setFace is called to verify if a face must be hidden
*/
void (*drawMappedFacesMat)(DerivedMesh *dm,
void (*setMaterial)(void *userData, int, void *attribs),
int (*setFace)(void *userData, int index), void *userData);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* Release reference to the DerivedMesh. This function decides internally
* if the DerivedMesh will be freed, or cached for later use. */
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
void (*release)(DerivedMesh *dm);
};
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* utility function to initialise a DerivedMesh's function pointers to
* the default implementation (for those functions which have a default)
*/
void DM_init_funcs(DerivedMesh *dm);
/* utility function to initialise a DerivedMesh for the desired number
* of vertices, edges and faces (doesn't allocate memory for them, just
* sets up the custom data layers)
*/
merge with trunk/2.5 at r25907
2010-01-13 07:26:11 +00:00
void DM_init(DerivedMesh *dm, DerivedMeshType type, int numVerts, int numEdges,
svn merge -r41751:41779 ^/trunk/blender
2011-11-15 02:05:32 +00:00
int numFaces, int numLoops, int numPolys);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* utility function to initialise a DerivedMesh for the desired number
* of vertices, edges and faces, with a layer setup copied from source
*/
void DM_from_template(DerivedMesh *dm, DerivedMesh *source,
part 1 of merge from trunk at r30358; it compiles, but doesn't link quite yet :)
2010-07-19 04:44:37 +00:00
DerivedMeshType type,
int numVerts, int numEdges, int numFaces,
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
int numLoops, int numPolys);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* utility function to release a DerivedMesh's layers
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
* returns 1 if DerivedMesh has to be released by the backend, 0 otherwise
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
*/
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
int DM_release(DerivedMesh *dm);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* utility function to convert a DerivedMesh to a Mesh
*/
=bmesh= modifiers can now be applied with shapekeys
2011-04-15 05:20:18 +00:00
void DM_to_mesh(DerivedMesh *dm, struct Mesh *me, struct Object *ob);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
* New option on modifiers that don't change topology: Apply as Shape Rather than applying the modifier to the object data, it will create a new shape with the deformed vertices in there. Only mesh at the moment, other object types on the todo.
2009-11-22 13:44:09 +00:00
/* utility function to convert a DerivedMesh to a shape key block
*/
void DM_to_meshkey(DerivedMesh *dm, struct Mesh *me, struct KeyBlock *kb);
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 17:42:03 +00:00
/* set the CD_FLAG_NOCOPY flag in custom data layers where the mask is
* zero for the layer type, so only layer types specified by the mask
* will be copied
*/
void DM_set_only_copy(DerivedMesh *dm, CustomDataMask mask);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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
Multiple UV and vertex color layers: (still work in progress) These can be created and deleted in the Mesh panel in the same place as before. There is always one active UV and vertex color layer, that is edited and displayed. Important things to do: - Render engine, material support - Multires and NMesh now lose non active layers Also CustomData changes to support muliple layers of the same type, and changes to layer allocation, updated documentation is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
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
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
*/
Multiple UV and vertex color layers: (still work in progress) These can be created and deleted in the Mesh panel in the same place as before. There is always one active UV and vertex color layer, that is edited and displayed. Important things to do: - Render engine, material support - Multires and NMesh now lose non active layers Also CustomData changes to support muliple layers of the same type, and changes to layer allocation, updated documentation is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
2006-12-12 21:29:09 +00:00
void DM_add_vert_layer(struct DerivedMesh *dm, int type, int alloctype,
quiet compiler warnings for BLI_array defines, split BLI_array_append into BLI_array_append / BLI_array_append_r, the latter returning the new array location.
2011-11-16 17:09:41 +00:00
void *layer);
Multiple UV and vertex color layers: (still work in progress) These can be created and deleted in the Mesh panel in the same place as before. There is always one active UV and vertex color layer, that is edited and displayed. Important things to do: - Render engine, material support - Multires and NMesh now lose non active layers Also CustomData changes to support muliple layers of the same type, and changes to layer allocation, updated documentation is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
2006-12-12 21:29:09 +00:00
void DM_add_edge_layer(struct DerivedMesh *dm, int type, int alloctype,
quiet compiler warnings for BLI_array defines, split BLI_array_append into BLI_array_append / BLI_array_append_r, the latter returning the new array location.
2011-11-16 17:09:41 +00:00
void *layer);
made the crash handler disabled by a command line flag, insted of being #ifdef'd out on release builds. also did little bit of work on subsurf. and face select can now deselect again, and fixed some other bugs with it (and subsurf).
2009-08-15 17:31:28 +00:00
void DM_add_tessface_layer(struct DerivedMesh *dm, int type, int alloctype,
quiet compiler warnings for BLI_array defines, split BLI_array_append into BLI_array_append / BLI_array_append_r, the latter returning the new array location.
2011-11-16 17:09:41 +00:00
void *layer);
void DM_add_loop_layer(DerivedMesh *dm, int type, int alloctype,
made the crash handler disabled by a command line flag, insted of being #ifdef'd out on release builds. also did little bit of work on subsurf. and face select can now deselect again, and fixed some other bugs with it (and subsurf).
2009-08-15 17:31:28 +00:00
void *layer);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void DM_add_poly_layer(struct DerivedMesh *dm, int type, int alloctype,
quiet compiler warnings for BLI_array defines, split BLI_array_append into BLI_array_append / BLI_array_append_r, the latter returning the new array location.
2011-11-16 17:09:41 +00:00
void *layer);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void *DM_get_tessface_data(struct DerivedMesh *dm, int index, int type);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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);
made the crash handler disabled by a command line flag, insted of being #ifdef'd out on release builds. also did little bit of work on subsurf. and face select can now deselect again, and fixed some other bugs with it (and subsurf).
2009-08-15 17:31:28 +00:00
void *DM_get_tessface_data_layer(struct DerivedMesh *dm, int type);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void *DM_get_poly_data_layer(struct DerivedMesh *dm, int type);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* custom data setting functions
* copy supplied data into first layer of type using layer's copy function
* (deep copy if appropriate)
*/
void DM_set_vert_data(struct DerivedMesh *dm, int index, int type, void *data);
void DM_set_edge_data(struct DerivedMesh *dm, int index, int type, void *data);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void DM_set_tessface_data(struct DerivedMesh *dm, int index, int type, void *data);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 17:42:03 +00:00
* these copy all layers for which the CD_FLAG_NOCOPY flag is not set
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
*/
void DM_copy_vert_data(struct DerivedMesh *source, struct DerivedMesh *dest,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int source_index, int dest_index, int count);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
void DM_copy_edge_data(struct DerivedMesh *source, struct DerivedMesh *dest,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int source_index, int dest_index, int count);
(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
void DM_copy_tessface_data(struct DerivedMesh *source, struct DerivedMesh *dest,
int source_index, int dest_index, int count);
void DM_copy_loop_data(struct DerivedMesh *source, struct DerivedMesh *dest,
int source_index, int dest_index, int count);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void DM_copy_poly_data(struct DerivedMesh *source, struct DerivedMesh *dest,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int source_index, int dest_index, int count);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* custom data free functions
* free count elements, starting at index
Multiple UV and vertex color layers: (still work in progress) These can be created and deleted in the Mesh panel in the same place as before. There is always one active UV and vertex color layer, that is edited and displayed. Important things to do: - Render engine, material support - Multires and NMesh now lose non active layers Also CustomData changes to support muliple layers of the same type, and changes to layer allocation, updated documentation is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData
2006-12-12 21:29:09 +00:00
* they free all layers for which the CD_FLAG_NOCOPY flag is not set
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
*/
void DM_free_vert_data(struct DerivedMesh *dm, int index, int count);
void DM_free_edge_data(struct DerivedMesh *dm, int index, int count);
(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
void DM_free_tessface_data(struct DerivedMesh *dm, int index, int count);
void DM_free_loop_data(struct DerivedMesh *dm, int index, int count);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void DM_free_poly_data(struct DerivedMesh *dm, int index, int count);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
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);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* interpolates vertex data from the vertices indexed by src_indices in the
* source mesh using the given weights and stores the result in the vertex
* indexed by dest_index in the dest mesh
*/
void DM_interp_vert_data(struct DerivedMesh *source, struct DerivedMesh *dest,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int *src_indices, float *weights,
int count, int dest_index);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* interpolates edge data from the edges indexed by src_indices in the
* source mesh using the given weights and stores the result in the edge indexed
* by dest_index in the dest mesh.
* if weights is NULL, all weights default to 1.
* if vert_weights is non-NULL, any per-vertex edge data is interpolated using
* vert_weights[i] multiplied by weights[i].
*/
typedef float EdgeVertWeight[SUB_ELEMS_EDGE][SUB_ELEMS_EDGE];
void DM_interp_edge_data(struct DerivedMesh *source, struct DerivedMesh *dest,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int *src_indices,
float *weights, EdgeVertWeight *vert_weights,
int count, int dest_index);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
/* interpolates face data from the faces indexed by src_indices in the
* source mesh using the given weights and stores the result in the face indexed
* by dest_index in the dest mesh.
* if weights is NULL, all weights default to 1.
* if vert_weights is non-NULL, any per-vertex face data is interpolated using
* vert_weights[i] multiplied by weights[i].
*/
typedef float FaceVertWeight[SUB_ELEMS_FACE][SUB_ELEMS_FACE];
(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
void DM_interp_tessface_data(struct DerivedMesh *source, struct DerivedMesh *dest,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
int *src_indices,
float *weights, FaceVertWeight *vert_weights,
int count, int dest_index);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 01:12:36 +00:00
part 1 of merge from trunk at r30358; it compiles, but doesn't link quite yet :)
2010-07-19 04:44:37 +00:00
void DM_swap_tessface_data(struct DerivedMesh *dm, int index, const int *corner_indices);
(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
void DM_interp_loop_data(struct DerivedMesh *source, struct DerivedMesh *dest,
int *src_indices,
float *weights, int count, int dest_index);
Rename DM *_face_* funcs to be either *_tessface_* or *_poly_* to avoid confusion This is the first step in a few changes to cleanup confusing/missing DM funcs
2011-11-29 05:09:54 +00:00
void DM_interp_poly_data(struct DerivedMesh *source, struct DerivedMesh *dest,
(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 *src_indices,
float *weights, int count, int dest_index);
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 10:35:14 +00:00
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 13:56:07 +00:00
/* Temporary? A function to give a colorband to derivedmesh for vertexcolor ranges */
void vDM_ColorBand_store(struct ColorBand *coba);
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
/* Simple function to get me->totvert amount of vertices/normals,
correctly deformed and subsurfered. Needed especially when vertexgroups are involved.
In use now by vertex/weigt paint and particles */
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
float *mesh_get_mapped_verts_nors(struct Scene *scene, struct Object *ob);
- added Mesh->derived and Mesh->decimated DerivedMesh pointers - removed DL_MESH displist type!!!! Now store a DerivedMesh directly. - May still be some issues left having to do with releasing this at the right time (old code just splashed free_displist all over the place).
2005-03-29 16:43:39 +00:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* */
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_get_derived_final(struct Scene *scene, struct Object *ob,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
CustomDataMask dataMask);
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_get_derived_deform(struct Scene *scene, struct Object *ob,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
CustomDataMask dataMask);
- added Mesh->derived and Mesh->decimated DerivedMesh pointers - removed DL_MESH displist type!!!! Now store a DerivedMesh directly. - May still be some issues left having to do with releasing this at the right time (old code just splashed free_displist all over the place).
2005-03-29 16:43:39 +00:00
=bmesh= modifiers can now be applied with shapekeys
2011-04-15 05:20:18 +00:00
DerivedMesh *mesh_create_derived_for_modifier(struct Scene *scene, struct Object *ob,
struct ModifierData *md, int build_shapekey_layers);
- added apply button for individual modifiers
2005-07-26 00:45:19 +00:00
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_create_derived_render(struct Scene *scene, struct Object *ob,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
CustomDataMask dataMask);
Phase1: fluidsim obstacles/control objects are grabbed from the specific position in modifier stack now (introducing new funciton in DerivedMesh.c), fixed some UI glitches.
2008-07-28 11:01:34 +00:00
renamed BMTessMesh to BMEditMesh, did some more monkeywork, cleaned up the more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
2009-05-18 08:46:04 +00:00
DerivedMesh *getEditDerivedBMesh(struct BMEditMesh *em, struct Object *ob,
NOTE: do not test. work-in-progress commit with editmesh ripped out and replaced with bmesh. this is not usable by any means. for those who read through this, note the design is still fairly messy in places, and fyi BMTessMesh is the replacement for EditMesh, I need to rename it to BMEditMesh.
2009-05-16 16:18:08 +00:00
float (*vertexCos)[3]);
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_create_derived_index_render(struct Scene *scene, struct Object *ob, CustomDataMask dataMask, int index);
Phase1: fluidsim obstacles/control objects are grabbed from the specific position in modifier stack now (introducing new funciton in DerivedMesh.c), fixed some UI glitches.
2008-07-28 11:01:34 +00:00
/* same as above but wont use render settings */
Made some function from DerivedMesh.c be avaliable from other modules. Some naming changes to make naming more uniform. No functional changes. It's necessery for further crazyspace changes and improvenments.
2011-02-11 15:15:35 +00:00
DerivedMesh *mesh_create_derived(struct Mesh *me, struct Object *ob, float (*vertCos)[3]);
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_create_derived_view(struct Scene *scene, struct Object *ob,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
CustomDataMask dataMask);
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_create_derived_no_deform(struct Scene *scene, struct Object *ob,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
float (*vertCos)[3],
CustomDataMask dataMask);
2.5 Think global, act local! The old favorite G.scene gone! Man... that took almost 2 days. Also removed G.curscreen and G.edbo. Not everything could get solved; here's some notes. - modifiers now store current scene in ModifierData. This is not meant for permanent, but it can probably stick there until we cleaned the anim system and depsgraph to cope better with timing issues. - Game engine G.scene should become an argument for staring it. Didn't solve this yet. - Texture nodes should get scene cfra, but the current implementation is too tightly wrapped to do it easily.
2009-01-04 14:14:06 +00:00
DerivedMesh *mesh_create_derived_no_deform_render(struct Scene *scene, struct Object *ob,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
float (*vertCos)[3],
CustomDataMask dataMask);
2.50: svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r19820:HEAD Notes: * Game and sequencer RNA, and sequencer header are now out of date a bit after changes in trunk. * I didn't know how to port these bugfixes, most likely they are not needed anymore. * Fix "duplicate strip" always increase the user count for ipo. * IPO pinning on sequencer strips was lost during Undo.
2009-06-08 20:08:19 +00:00
/* for gameengine */
DerivedMesh *mesh_create_derived_no_virtual(struct Scene *scene, struct Object *ob, float (*vertCos)[3],
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
CustomDataMask dataMask);
BGE: support modifiers without mapping to original mesh both graphically and physically, fixes bug #24942 and #25286. Support for physics is done by skiping the modifiers that don't support mapping to original mesh. This mapping is required to report the hit polygon to the application by the rayCast() function. Support for graphics is done by using the same render function that blender uses for the 3D view. This guantees equal result. Limitation: there is still a known bug if all these conditions are met: - Display list enabled - Old tex face with a several textures mapped to the same material - no armature or shape keys - active modifiers In this case, only a part of the mesh will be rendered with the wrong texture. To avoid this bug, use the GLSL materials or make sure to have 1 material=1 texture in your old tex face objects.
2011-01-23 17:17:21 +00:00
DerivedMesh *mesh_create_derived_physics(struct Scene *scene, struct Object *ob, float (*vertCos)[3],
CustomDataMask dataMask);
- added DerivedMesh.getVertCos function and implementations - added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-18 19:58:23 +00:00
merge with/from trunk at r35190
2011-02-27 06:19:40 +00:00
DerivedMesh *editbmesh_get_derived(struct BMEditMesh *em, float (*vertexCos)[3]);
renamed BMTessMesh to BMEditMesh, did some more monkeywork, cleaned up the more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
2009-05-18 08:46:04 +00:00
DerivedMesh *editbmesh_get_derived_base(struct Object *, struct BMEditMesh *em);
NOTE: do not test. work-in-progress commit with editmesh ripped out and replaced with bmesh. this is not usable by any means. for those who read through this, note the design is still fairly messy in places, and fyi BMTessMesh is the replacement for EditMesh, I need to rename it to BMEditMesh.
2009-05-16 16:18:08 +00:00
DerivedMesh *editbmesh_get_derived_cage(struct Scene *scene, struct Object *,
renamed BMTessMesh to BMEditMesh, did some more monkeywork, cleaned up the more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
2009-05-18 08:46:04 +00:00
struct BMEditMesh *em, CustomDataMask dataMask);
NOTE: do not test. work-in-progress commit with editmesh ripped out and replaced with bmesh. this is not usable by any means. for those who read through this, note the design is still fairly messy in places, and fyi BMTessMesh is the replacement for EditMesh, I need to rename it to BMEditMesh.
2009-05-16 16:18:08 +00:00
DerivedMesh *editbmesh_get_derived_cage_and_final(struct Scene *scene, struct Object *,
renamed BMTessMesh to BMEditMesh, did some more monkeywork, cleaned up the more serious warnings, and also non-backbuffered selection sortof works now, though it still needs plenty of work.
2009-05-18 08:46:04 +00:00
struct BMEditMesh *em, DerivedMesh **final_r,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
CustomDataMask dataMask);
merge with/from trunk at r35190
2011-02-27 06:19:40 +00:00
float (*editbmesh_get_vertex_cos(struct BMEditMesh *em, int *numVerts_r))[3];
int editbmesh_modifier_is_enabled(struct Scene *scene, struct ModifierData *md, DerivedMesh *dm);
=bmesh= modifiers can now be applied with shapekeys
2011-04-15 05:20:18 +00:00
void makeDerivedMesh(struct Scene *scene, struct Object *ob, struct BMEditMesh *em,
CustomDataMask dataMask, int build_shapekey_layers);
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 05:58:43 +00:00
Armature CrazySpace Improvement =============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2007-07-28 21:04:30 +00:00
/* returns an array of deform matrices for crazyspace correction, and the
number of modifiers left */
BMesh branch ------------ Fix some gcc warnings and errors (under linux anyway).
2010-03-11 18:27:45 +00:00
int editbmesh_get_first_deform_matrices(struct Scene *, struct Object *, struct BMEditMesh *em,
spaces -> tabs, (4 spaces == 1 tab, only for white space preceding text)
2010-03-22 09:30:00 +00:00
float (**deformmats)[3][3], float (**deformcos)[3]);
Armature CrazySpace Improvement =============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2007-07-28 21:04:30 +00:00
Sculpting on deformed mesh ========================== Removed limitation of armatured-only objects for sculpting -- now all deformation modifiers are allowed in sculpt mode. Use crazyspace corrections like from transformation modules was used to support all deformation modifiers. Internal change: all crazyspace-related functions were noved to crazyspace.c P.S. Brush could make quite unexpected deformation for meshes which are deformed in specified way. Got patch for this and discussing with Brecht if it's really needed or maybe it could be done in better way.
2011-02-12 17:51:02 +00:00
/* returns an array of deform matrices for crazyspace correction when sculpting,
and the number of modifiers left */
int sculpt_get_deform_matrices(struct Scene *scene, struct Object *ob,
Todo issue: sculpting on deformed mesh Used a crazyspace approach (like in edit mode), but only modifiers with deformMatricies are allowed atm (currently shapekeys and armature modifiers only). All the rest modifiers had an warning message that they aren't applied because of sculpt mode. Deformation of multires is also unsupported. With all this restictions users will always see the actual "layer" (or maybe mesh state would be more correct word) they are sculpting on. Internal changes: - All modifiers could have deformMatricies callback (the same as deformMatriciesEM but for non-edit mode usage) - Added function to build crazyspace for sculpting (sculpt_get_deform_matrices), but it could be generalized for usage in other painting modes (particle edit mode, i.e) Todo: - Implement crazyspace correction to support all kinds of deformation modifiers - Maybe deformation of multires isn't so difficult? - And maybe we could avoid extra bad-level-stub for ED_sculpt_modifiers_changed without code duplicating?
2011-01-31 20:02:51 +00:00
float (**deformmats)[3][3], float (**deformcos)[3]);
minor edit - weight_to_rgb() and ramp_blend() now take a float vector rather than 3 float pointers. also make particle draw use a float vec.
2011-11-26 03:13:54 +00:00
void weight_to_rgb(float r_rgb[3], const float weight);
Animation department feature request: support for vertex groups in Lattices In a quick glance: (temp image) http://www.blender.org/bf/rt.png Main reason is that Lattices are useful a lot for Armature deformation. Lattices just provide much more precise and interesting control. However, with only bone envelopes it's very hard to use. Working with Lattice vertex groups is nearly identical to Mesh: - on CTRL+P 'make parent' you can choose the deform option now - In editmode, the buttons to control vertex groups are available - In outliner you can select vertexgroups too - Deforming Lattices with Armatures has all options as for Mesh now. Note: - No WeightPaint has been added yet. To compensate, the editmode drawing for a Lattice with vertex group shows weight values for the active vertex group. - Lattice editmode doesn't undo/redo weight editing yet. - Softbody for Lattice still uses own vertex weights Implementation notes: - derivedmesh weight_to_rgb() is now exported to drawobject.c - been doing cleanups in code (order of includes, var declarations, etc) - weightpaint button handling now is generic I've checked on Brecht's proposal for Custom Element data; http://mediawiki.blender.org/index.php/BlenderDev/CustomElementData It could have been used, but that would mean the existing code for vertexgroup handling and armature deform couldn't be re-used. I guess this is really a later todo.
2006-09-03 12:16:14 +00:00
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 20:51:28 +00:00
/* convert layers requested by a GLSL material to actually available layers in
* the DerivedMesh, with both a pointer for arrays and an offset for editmesh */
typedef struct DMVertexAttribs {
struct {
struct MTFace *array;
Code cleanup: small glsl mesh drawing code changes, getting rid of an ugly macro.
2011-08-12 18:17:28 +00:00
int emOffset, glIndex, glTexco;
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 20:51:28 +00:00
} tface[MAX_MTFACE];
struct {
struct MCol *array;
int emOffset, glIndex;
} mcol[MAX_MCOL];
struct {
This commit will switch blender to use tangent space generated within the two files mikktspace.h and mikktspace.c. These are standalone files which can be redistributed into any other application and regenerate the same tangent spaces. The implementation is independent of the ordering of faces and the vertex ordering of faces.
2011-02-14 18:18:46 +00:00
float (*array)[4];
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 20:51:28 +00:00
int emOffset, glIndex;
} tang;
struct {
float (*array)[3];
Code cleanup: small glsl mesh drawing code changes, getting rid of an ugly macro.
2011-08-12 18:17:28 +00:00
int emOffset, glIndex, glTexco;
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 20:51:28 +00:00
} orco;
int tottface, totmcol, tottang, totorco;
} DMVertexAttribs;
void DM_vertex_attributes_from_gpu(DerivedMesh *dm,
struct GPUVertexAttribs *gattribs, DMVertexAttribs *attribs);
Game Engine: alpha blending and sorting ======================================= Alpha blending + sorting was revised, to fix bugs and get it to work more predictable. * A new per texture face "Sort" setting defines if the face is alpha sorted or not, instead of abusing the "ZTransp" setting as it did before. * Existing files are converted to hopefully match the old behavior as much as possible with a version patch. * On new meshes the Sort flag is disabled by the default, to avoid unexpected and hard to find slowdowns. * Alpha sorting for faces was incredibly slow. Sorting faces in a mesh with 600 faces lowered the framerate from 200 to 70 fps in my test.. the sorting there case goes about 15x faster now, but it is still advised to use Clip Alpha if possible instead of regular Alpha. * There still various limitations in the alpha sorting code, I've added some comments to the code about this. Some docs at the bottom of the page: http://www.blender.org/development/current-projects/changes-since-246/realtime-glsl-materials/ Merged some fixes from the apricot branch, most important change is that tangents are now exactly the same as the rest of Blender, instead of being computed in the game engine with a different algorithm. Also, the subversion was bumped to 1.
2008-07-29 15:48:31 +00:00
void DM_add_tangent_layer(DerivedMesh *dm);
Constructive modifiers for curves and surfaces Used approach with creating DerivedMesh for curves whet they've got such modifiers. Available modifiers are: array, edge split, mirror, solidify, subsurf.
2010-03-05 16:47:52 +00:00
/* Set object's bounding box based on DerivedMesh min/max data */
void DM_set_object_boundbox(struct Object *ob, DerivedMesh *dm);
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 20:34:18 +00:00
#endif
Copy Permalink