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
bde80cbb14133c6feb55d0ec1e26cf87b6dcb378
blender-archive/source/blender/blenkernel/intern/cdderivedmesh.c

3590 lines
102 KiB
C
Raw Normal View History

style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
/*
header cleanup (no functional changes)
2011-10-10 09:38:02 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2006 Blender Foundation.
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): Ben Batt <benbatt@gmail.com>
*
* ***** END GPL LICENSE BLOCK *****
*
* Implementation of CDDerivedMesh.
*
* BKE_cdderivedmesh.h contains the function prototypes for this file.
*
*/
doxygen: blender/blenkernel tagged.
2011-02-27 20:40:57 +00:00
/** \file blender/blenkernel/intern/cdderivedmesh.c
* \ingroup bke
*/
header cleanup (no functional changes)
2011-10-10 09:38:02 +00:00
Math Lib * Convert all code to use new functions. * Branch maintainers may want to skip this commit, and run this conversion script instead, if they use a lot of math functions in new code: http://www.pasteall.org/9052/python
2009-11-10 20:43:45 +00:00
#include "BLI_math.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
#include "BLI_edgehash.h"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BLI_utildefines.h"
move STACK_* macros into BLI_stackdefines.h
2014-06-25 00:01:10 +10:00
#include "BLI_stackdefines.h"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
move pbvh into BKE, it used many BKE bad level includes. now blenlib/BLI doesn't depend on any blenkern/BKE functions, there are still some bad level includes but these are only to access G.background and the blender version define.
2012-12-15 15:59:25 +00:00
#include "BKE_pbvh.h"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BKE_cdderivedmesh.h"
#include "BKE_global.h"
#include "BKE_mesh.h"
Code Cleanup: move mesh mapping functions into their own file/header
2013-12-12 16:26:11 +11:00
#include "BKE_mesh_mapping.h"
split BKE_utildefines.h, now it only has blender specific defines like GS() MAKE_ID, FILE_MAXDIR, moved the generic defines to BLI_utildefines.h. no functional changes.
2011-01-07 18:36:47 +00:00
#include "BKE_paint.h"
code cleanup: rename BKE_tessmesh -> BKE_editmesh, rename EditDerivedBMesh.tc -> em. ('tc' is odd name which isn't used elsewhere).
2013-04-13 20:31:52 +00:00
#include "BKE_editmesh.h"
support for curve orco uv's as UV's in cycles. ideally these would be used as generated coordinates, but this is tricly because cycles calculates its own orco's and doesnt know about curve settings.
2012-07-31 13:43:26 +00:00
#include "BKE_curve.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
- remove some unused editmesh functions. - copy & rename EditMesh stricts for use with scanfill (remove unused members)
2012-02-19 22:17:30 +00:00
#include "DNA_mesh_types.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
#include "DNA_meshdata_types.h"
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
#include "DNA_object_types.h"
- Fixed trouble with rendering curves with disabled modifiers, which are disabled for realtime displaying but enabled for rendering. - Calculate tex space for curves before modifiers applying.
2010-03-08 13:49:13 +00:00
#include "DNA_curve_types.h" /* for Curve */
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
#include "MEM_guardedalloc.h"
Fix a few compile warnings and rename gpu_buffers.h to GPU_buffers.h for consistency.
2010-07-14 10:46:12 +00:00
#include "GPU_buffers.h"
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
#include "GPU_draw.h"
Ghost Context Refactor https://developer.blender.org/D643 Separates graphics context creation from window code in Ghost so that they can vary separately.
2014-10-07 15:46:19 -05:00
#include "GPU_glew.h"
OpenGL: split off framebuffer, shader and texture code into separate files.
2015-12-06 21:20:19 +01:00
#include "GPU_shader.h"
OpenGL: stipple support added to basic GLSL shader The is intended to replace the deprecated glPolygonStipple() calls with a shader based alternative, once we switch over to GLSL shaders. Reviewers: brecht Differential Revision: https://developer.blender.org/D1688
2015-12-25 22:57:50 +01:00
#include "GPU_basic_shader.h"
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
#include "WM_api.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
#include <string.h>
#include <limits.h>
Got rid of old multires code, brought in multires modifier from soc-2008-nicholasbishop branch. Note: any old code with multires_test() or multires_level1_test() can just be deleted, not needed by the multires modifier.
2009-01-06 18:59:03 +00:00
#include <math.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
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
typedef struct {
DerivedMesh dm;
/* these point to data in the DerivedMesh custom data layers,
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* they are only here for efficiency and convenience **/
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MVert *mvert;
MEdge *medge;
MFace *mface;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
MLoop *mloop;
MPoly *mpoly;
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
/* Cached */
struct PBVH *pbvh;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool pbvh_draw;
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
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
/* Mesh connectivity */
Reduce poly map memory usage (used by sculpt smooth brush.) Changed the create_vert_poly_map function to return a more compact structure. Memory saved will vary depending on the mesh, but typically it should be about one third of the old size.
2012-03-17 04:41:36 +00:00
MeshElemMap *pmap;
int *pmap_mem;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
} CDDerivedMesh;
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
/**************** DerivedMesh interface functions ****************/
static int cdDM_getNumVerts(DerivedMesh *dm)
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
return dm->numVertData;
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
static int cdDM_getNumEdges(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
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
return dm->numEdgeData;
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
static int cdDM_getNumTessFaces(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
{
fix for emitting particles (needed tessfaces). this fixes the cloud-gen addon.
2012-02-27 09:37:59 +00:00
/* uncomment and add a breakpoint on the printf()
* to help debug tessfaces issues since BMESH merge. */
#if 0
if (dm->numTessFaceData == 0 && dm->numPolyData != 0) {
printf("%s: has no faces!, call DM_ensure_tessface() if you need them\n");
}
#endif
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
return dm->numTessFaceData;
}
static int cdDM_getNumLoops(DerivedMesh *dm)
{
return dm->numLoopData;
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
}
More DM func renames, this one includes renames of the function pointer members of the DerivedMesh struct
2011-11-29 13:01:51 +00:00
static int cdDM_getNumPolys(DerivedMesh *dm)
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
{
return dm->numPolyData;
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getVert(DerivedMesh *dm, int index, MVert *r_vert)
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
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
*r_vert = cddm->mvert[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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getEdge(DerivedMesh *dm, int index, MEdge *r_edge)
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
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
*r_edge = cddm->medge[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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getTessFace(DerivedMesh *dm, int index, MFace *r_face)
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
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
*r_face = cddm->mface[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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_copyVertArray(DerivedMesh *dm, MVert *r_vert)
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
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
memcpy(r_vert, cddm->mvert, sizeof(*r_vert) * dm->numVertData);
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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_copyEdgeArray(DerivedMesh *dm, MEdge *r_edge)
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
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
memcpy(r_edge, cddm->medge, sizeof(*r_edge) * dm->numEdgeData);
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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_copyTessFaceArray(DerivedMesh *dm, MFace *r_face)
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
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
memcpy(r_face, cddm->mface, sizeof(*r_face) * dm->numTessFaceData);
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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_copyLoopArray(DerivedMesh *dm, MLoop *r_loop)
=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
{
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
memcpy(r_loop, cddm->mloop, sizeof(*r_loop) * dm->numLoopData);
=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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_copyPolyArray(DerivedMesh *dm, MPoly *r_poly)
=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
{
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
memcpy(r_poly, cddm->mpoly, sizeof(*r_poly) * dm->numPolyData);
=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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getMinMax(DerivedMesh *dm, float r_min[3], float r_max[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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) 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 i;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
if (dm->numVertData) {
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < dm->numVertData; i++) {
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
minmax_v3v3_v3(r_min, r_max, cddm->mvert[i].co);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
}
code cleanup: use zero_v3
2012-03-23 20:18:09 +00:00
}
else {
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
zero_v3(r_min);
zero_v3(r_max);
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
}
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getVertCo(DerivedMesh *dm, int index, float r_co[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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
copy_v3_v3(r_co, cddm->mvert[index].co);
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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getVertCos(DerivedMesh *dm, float (*r_cos)[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
{
MVert *mv = CDDM_get_verts(dm);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
int i;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
for (i = 0; i < dm->numVertData; i++, mv++)
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
copy_v3_v3(r_cos[i], mv->co);
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
}
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
static void cdDM_getVertNo(DerivedMesh *dm, int index, float r_no[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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Code cleanup: use r_ prefix for return args
2014-03-16 03:24:05 +11:00
normal_short_to_float_v3(r_no, cddm->mvert[index].no);
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
}
Make grumpy gcc happy again! :p
2012-03-17 10:23:44 +00:00
static const MeshElemMap *cdDM_getPolyMap(Object *ob, DerivedMesh *dm)
add function for getting a polygon map: dm->getPolyMap(ob, dm). polygon version of dm->getFaceMap(ob, dm) sculpt uses this for checking connectivity.
2012-02-05 06:20:51 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
add function for getting a polygon map: dm->getPolyMap(ob, dm). polygon version of dm->getFaceMap(ob, dm) sculpt uses this for checking connectivity.
2012-02-05 06:20:51 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!cddm->pmap && ob->type == OB_MESH) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
Mesh *me = ob->data;
add function for getting a polygon map: dm->getPolyMap(ob, dm). polygon version of dm->getFaceMap(ob, dm) sculpt uses this for checking connectivity.
2012-02-05 06:20:51 +00:00
Cleanup: ws
2015-07-15 12:08:32 +10:00
BKE_mesh_vert_poly_map_create(
&cddm->pmap, &cddm->pmap_mem,
me->mpoly, me->mloop,
me->totvert, me->totpoly, me->totloop);
add function for getting a polygon map: dm->getPolyMap(ob, dm). polygon version of dm->getFaceMap(ob, dm) sculpt uses this for checking connectivity.
2012-02-05 06:20:51 +00:00
}
return cddm->pmap;
}
Over-optimized stuff in the previous commit, sorry.
2014-05-06 16:55:50 +02:00
static bool check_sculpt_object_deformed(Object *object, bool for_construction)
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
{
Cleanup a bit of the locked shape keys painting It's still gives some slowdown when painting a locked key in the solid view, but since shape key is now longer being re-used by DM. but this change should still give some degree of speedup propagating delta onto the keyblock if i remember the code correct.
2014-05-06 14:49:50 +02:00
bool deformed = false;
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
Cleanup a bit of the locked shape keys painting It's still gives some slowdown when painting a locked key in the solid view, but since shape key is now longer being re-used by DM. but this change should still give some degree of speedup propagating delta onto the keyblock if i remember the code correct.
2014-05-06 14:49:50 +02:00
/* Active modifiers means extra deformation, which can't be handled correct
code cleanup: typos and set gcc attributes for string formatting.
2012-04-25 06:06:40 +00:00
* on birth of PBVH and sculpt "layer" levels, so use PBVH only for internal brush
Cleanup a bit of the locked shape keys painting It's still gives some slowdown when painting a locked key in the solid view, but since shape key is now longer being re-used by DM. but this change should still give some degree of speedup propagating delta onto the keyblock if i remember the code correct.
2014-05-06 14:49:50 +02:00
* stuff and show final DerivedMesh so user would see actual object shape.
*/
deformed |= object->sculpt->modifiers_active;
Sculpting on shapekeys ====================== All this work with sculpting on armatured/deformed mesh allowed to implement sculpting on non-locked keys very easy -- just use the same approach of propagating offsets from deformed PBVH to "sculpting layer". - If key is locked, then old logic would be used. - If there's multires modifier enabled, sculpting would happen on multires.
2011-04-23 09:07:46 +00:00
Over-optimized stuff in the previous commit, sorry.
2014-05-06 16:55:50 +02:00
if (for_construction) {
deformed |= object->sculpt->kb != NULL;
}
else {
/* As in case with modifiers, we can't synchronize deformation made against
* PBVH and non-locked keyblock, so also use PBVH only for brushes and
* final DM to give final result to user.
*/
deformed |= object->sculpt->kb && (object->shapeflag & OB_SHAPE_LOCK) == 0;
}
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
Cleanup a bit of the locked shape keys painting It's still gives some slowdown when painting a locked key in the solid view, but since shape key is now longer being re-used by DM. but this change should still give some degree of speedup propagating delta onto the keyblock if i remember the code correct.
2014-05-06 14:49:50 +02:00
return deformed;
}
static bool can_pbvh_draw(Object *ob, DerivedMesh *dm)
{
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Mesh *me = ob->data;
Over-optimized stuff in the previous commit, sorry.
2014-05-06 16:55:50 +02:00
bool deformed = check_sculpt_object_deformed(ob, false);
Cleanup a bit of the locked shape keys painting It's still gives some slowdown when painting a locked key in the solid view, but since shape key is now longer being re-used by DM. but this change should still give some degree of speedup propagating delta onto the keyblock if i remember the code correct.
2014-05-06 14:49:50 +02:00
if (deformed) {
return false;
}
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
bmesh: proper sculpting on non-multires object Problem was caused by unneeded call of CDDM_calc_normals when creating derived mesh for object which duplicated mvert array. It shouldn't happen unless object has got shapekeys or deformation modifiers on the top of stack.
2011-09-07 12:47:23 +00:00
return cddm->mvert == me->mvert || ob->sculpt->kb;
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
}
style cleanup: mainly sculpt/whitespace
2012-05-11 08:05:47 +00:00
static PBVH *cdDM_getPBVH(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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) 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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!ob) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cddm->pbvh = NULL;
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
return NULL;
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!ob->sculpt)
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
return NULL;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (ob->sculpt->pbvh) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cddm->pbvh = ob->sculpt->pbvh;
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
cddm->pbvh_draw = can_pbvh_draw(ob, dm);
Sculpt & modifiers: patch by Sergey Sharybin, with modifications by me. Fixes various crashes and redraw problems, most noticeable new feature is that you can now sculpt on a multires mesh with deforming modifiers preceding it. I've left out support for sculpting on multires with enabled modifiers following it, in this case only the base mesh can be sculpted now. The code changes needed to do this are just too ugly in my opinion, would need a more torough redesign which I don't think we should try now. In my opinion this is also not really an important case, since it's going to be incredibly slow anyway to run a modifier on a high res mesh while sculpting. So, to summarize current state: * Fastest sculpting: base mesh with no modifiers or multires with only modifiers preceding it. * Slower sculpting: base mesh with modifiers, depends on the speed of the modifiers. * Not supported: multires mesh with modifiers following it.
2010-06-02 18:04:31 +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
Update DerivedMesh for dynamic-topology sculpt mode * Build bmesh PBVH in CDDM when dyntopo is enabled * Disable all modifiers when dyntopo is enabled
2012-12-30 18:29:41 +00:00
/* Sculpting on a BMesh (dynamic-topology) gets a special PBVH */
if (!cddm->pbvh && ob->sculpt->bm) {
Code cleanup: rename BLI_pbvh to BKE_pbvh
2012-12-30 18:31:31 +00:00
cddm->pbvh = BKE_pbvh_new();
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
cddm->pbvh_draw = true;
Update DerivedMesh for dynamic-topology sculpt mode * Build bmesh PBVH in CDDM when dyntopo is enabled * Disable all modifiers when dyntopo is enabled
2012-12-30 18:29:41 +00:00
Code cleanup: rename BLI_pbvh to BKE_pbvh
2012-12-30 18:31:31 +00:00
BKE_pbvh_build_bmesh(cddm->pbvh, ob->sculpt->bm,
style cleanup
2013-01-02 01:49:07 +00:00
ob->sculpt->bm_smooth_shading,
Refactor to Dyntopo node customdata commit. Don't use a dedicated node layer but use temporary int layer instead. Works like a charm as long as we are careful resetting the layer when needed (after pbvh clearing and always after bmesh has been filled in undo) Tip by Campbell, thanks!
2014-04-17 19:02:55 +03:00
ob->sculpt->bm_log, ob->sculpt->cd_vert_node_offset,
ob->sculpt->cd_face_node_offset);
Fix T39517, Issue here is that "show diffuse" option does not respect its intended purpose which is to be used only for masking. There are a couple of caveats here: Dyntopo and multires -always- have mask data enabled, and thus as soon as one goes to dyntopo mode or adds a multires modifier he would get the default grey color instead. Matcaps would break when nodes asked for a diffuse material color (this was broken before too). Solved by adding global material state for when matcaps are enabled. Also matcaps don't always played well with VBOs off. Added a few more missing updates for mask operators to notify show_diffuse property as changed. This was also needed on rebuilding dyntopo pbvh. Also make zero mask color duller again after artist feedback.
2014-04-02 17:33:47 +03:00
pbvh_show_diffuse_color_set(cddm->pbvh, ob->sculpt->show_diffuse_color);
Update DerivedMesh for dynamic-topology sculpt mode * Build bmesh PBVH in CDDM when dyntopo is enabled * Disable all modifiers when dyntopo is enabled
2012-12-30 18:29:41 +00:00
}
Sculpt & modifiers: patch by Sergey Sharybin, with modifications by me. Fixes various crashes and redraw problems, most noticeable new feature is that you can now sculpt on a multires mesh with deforming modifiers preceding it. I've left out support for sculpting on multires with enabled modifiers following it, in this case only the base mesh can be sculpted now. The code changes needed to do this are just too ugly in my opinion, would need a more torough redesign which I don't think we should try now. In my opinion this is also not really an important case, since it's going to be incredibly slow anyway to run a modifier on a high res mesh while sculpting. So, to summarize current state: * Fastest sculpting: base mesh with no modifiers or multires with only modifiers preceding it. * Slower sculpting: base mesh with modifiers, depends on the speed of the modifiers. * Not supported: multires mesh with modifiers following it.
2010-06-02 18:04:31 +00:00
/* always build pbvh from original mesh, and only use it for drawing if
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* this derivedmesh is just original mesh. it's the multires subsurf dm
* that this is actually for, to support a pbvh on a modified mesh */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!cddm->pbvh && ob->type == OB_MESH) {
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
Mesh *me = ob->data;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const int looptris_num = poly_to_tri_count(me->totpoly, me->totloop);
MLoopTri *looptri;
Cleanup a bit of the locked shape keys painting It's still gives some slowdown when painting a locked key in the solid view, but since shape key is now longer being re-used by DM. but this change should still give some degree of speedup propagating delta onto the keyblock if i remember the code correct.
2014-05-06 14:49:50 +02:00
bool deformed;
Fox #31185: Cannot sculpt shape keys Was related on sculpting on locked keys. Issue was caused by building PBVH from base mesh which is now doesn't have shape key loaded into it as it was in 2.62. Fixed by loading coordinates from deformed mesh into PBVH like it happens for on-locked shape keys.
2012-05-01 12:14:44 +00:00
Code cleanup: rename BLI_pbvh to BKE_pbvh
2012-12-30 18:31:31 +00:00
cddm->pbvh = BKE_pbvh_new();
[#22262] Sculpting shape keys using the Smooth brush switches the shape to the Basis PBVH used the same verts array as mesh data and shape key/reference key coords were applying on the mesh data, so on some refreshing undeformed mesh was displayed. Added utility functions to get vert coords from key block, apply new vert coords on keyblock and function to apply coords on bpvh, so now pbvh uses it's ovn vertex array and no changes are making to the mesh data. Additional change: Store key block name in SculptUndoNode, so now shape wouldn't be copied to wrong keyblock on undo
2010-06-21 20:10:59 +00:00
cddm->pbvh_draw = can_pbvh_draw(ob, dm);
Don't wait for sculpt stroke to create PBVH. This idea is borrowed from the multires modifier, which already checked if the object was in sculpt mode and, if so, created the PBVH. That check is now moved higher up the chain into mesh_build_data(), so that it occurs for CDDerivedMesh too. This also replaces an assert in cdDM_getPBVH for tesselated mesh faces with a call to create them if missing.
2012-03-14 06:30:55 +00:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
looptri = MEM_mallocN(sizeof(*looptri) * looptris_num, __func__);
BKE_mesh_recalc_looptri(
me->mloop, me->mpoly,
me->mvert,
me->totloop, me->totpoly,
looptri);
Don't wait for sculpt stroke to create PBVH. This idea is borrowed from the multires modifier, which already checked if the object was in sculpt mode and, if so, created the PBVH. That check is now moved higher up the chain into mesh_build_data(), so that it occurs for CDDerivedMesh too. This also replaces an assert in cdDM_getPBVH for tesselated mesh faces with a call to create them if missing.
2012-03-14 06:30:55 +00:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
BKE_pbvh_build_mesh(
cddm->pbvh,
me->mpoly, me->mloop,
me->mvert, me->totvert, &me->vdata,
looptri, looptris_num);
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
Fix first part of T39956 show diffuse option not correctly calculated on opening a file. Make sure we call pbvh_show_diffuse_color_set after building the pbvh so vertex data are available to it.
2014-05-01 02:11:39 +03:00
pbvh_show_diffuse_color_set(cddm->pbvh, ob->sculpt->show_diffuse_color);
Over-optimized stuff in the previous commit, sorry.
2014-05-06 16:55:50 +02:00
deformed = check_sculpt_object_deformed(ob, true);
Fox #31185: Cannot sculpt shape keys Was related on sculpting on locked keys. Issue was caused by building PBVH from base mesh which is now doesn't have shape key loaded into it as it was in 2.62. Fixed by loading coordinates from deformed mesh into PBVH like it happens for on-locked shape keys.
2012-05-01 12:14:44 +00:00
if (deformed && ob->derivedDeform) {
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
DerivedMesh *deformdm = ob->derivedDeform;
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 (*vertCos)[3];
int totvert;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
totvert = deformdm->getNumVerts(deformdm);
Code cleanup: no need to use calloc when memory is initialized after also replace AT with __func__ since AT expands the full pathname
2014-04-04 14:26:01 +11:00
vertCos = MEM_mallocN(totvert * sizeof(float[3]), "cdDM_getPBVH vertCos");
Own TODO item: sculpting on constructive modifiers - Constructive modifiers are enabled by default in sculpt mode. - There's option to disable all constructive modifiers in the "Options" panel of toolbox in sculpt mode, - Use one column in options panel to make strings easier to read - No modifiers would still be applied on multires
2011-05-04 13:15:42 +00:00
deformdm->getVertCos(deformdm, vertCos);
Code cleanup: rename BLI_pbvh to BKE_pbvh
2012-12-30 18:31:31 +00:00
BKE_pbvh_apply_vertCos(cddm->pbvh, vertCos);
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
MEM_freeN(vertCos);
}
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
}
return cddm->pbvh;
}
Fixed bug #23922, Sculpting - Textured display draws incorrectly Root cause is that some drawing modes don't work with PBVH drawing. Worked around by adding a call to update mesh normals from the PBVH so that sculpted changes appear correctly in those "unsupported" modes. (They'll still draw much more slowly than solid, but should at least appear correct now.)
2010-12-14 03:30:30 +00:00
/* update vertex normals so that drawing smooth faces works during sculpt
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* TODO: proper fix is to support the pbvh in all drawing modes */
Fixed bug #23922, Sculpting - Textured display draws incorrectly Root cause is that some drawing modes don't work with PBVH drawing. Worked around by adding a call to update mesh normals from the PBVH so that sculpted changes appear correctly in those "unsupported" modes. (They'll still draw much more slowly than solid, but should at least appear correct now.)
2010-12-14 03:30:30 +00:00
static void cdDM_update_normals_from_pbvh(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Fixed bug #23922, Sculpting - Textured display draws incorrectly Root cause is that some drawing modes don't work with PBVH drawing. Worked around by adding a call to update mesh normals from the PBVH so that sculpted changes appear correctly in those "unsupported" modes. (They'll still draw much more slowly than solid, but should at least appear correct now.)
2010-12-14 03:30:30 +00:00
float (*face_nors)[3];
Changes around update normals from PBVH to CDDM - Only do this if PBVH is not used for display, this should correspond to whats' happening in sculpt.c now. - No need to do such synchronization for solid drawing, it supports optimal display from PBVH. In fact, such synchronization is only needed in the following case: Drawing callback does not support PBVH draw and sculpt session is configured to use PBVH for display and related operations.
2016-01-15 16:29:57 +05:00
/* Some callbacks do not use optimal PBVH draw, so needs all the
* possible data (like normals) to be copied from PBVH back to DM.
*
* This is safe to do if PBVH and DM are representing the same mesh,
* which could be wrong when modifiers are enabled for sculpt.
* So here we only doing update when there's no modifiers applied
* during sculpt.
*
* It's safe to do nothing if there are modifiers, because in this
* case modifier stack is re-constructed from scratch on every
* update.
*/
Cleanup: style
2016-01-16 13:01:10 +11:00
if (!cddm->pbvh_draw) {
Fix T47170: Sculpt w/ constructive modifier crash Regression in 4d33c37c9 Only copy normal arrays from sculpt to the DerivedMesh when the mesh is deformed. Constructive modifiers calculate their own normals.
2016-01-14 10:04:24 +11:00
return;
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
face_nors = CustomData_get_layer(&dm->polyData, CD_NORMAL);
Fixed bug #23922, Sculpting - Textured display draws incorrectly Root cause is that some drawing modes don't work with PBVH drawing. Worked around by adding a call to update mesh normals from the PBVH so that sculpted changes appear correctly in those "unsupported" modes. (They'll still draw much more slowly than solid, but should at least appear correct now.)
2010-12-14 03:30:30 +00:00
Code cleanup: rename BLI_pbvh to BKE_pbvh
2012-12-30 18:31:31 +00:00
BKE_pbvh_update(cddm->pbvh, PBVH_UpdateNormals, face_nors);
Fixed bug #23922, Sculpting - Textured display draws incorrectly Root cause is that some drawing modes don't work with PBVH drawing. Worked around by adding a call to update mesh normals from the PBVH so that sculpted changes appear correctly in those "unsupported" modes. (They'll still draw much more slowly than solid, but should at least appear correct now.)
2010-12-14 03:30:30 +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
static void cdDM_drawVerts(DerivedMesh *dm)
{
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
GPU_vertex_setup(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (dm->drawObject->tot_loop_verts)
glDrawArrays(GL_POINTS, 0, dm->drawObject->tot_loop_verts);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
else
glDrawArrays(GL_POINTS, 0, dm->drawObject->tot_loose_point);
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
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
}
static void cdDM_drawUVEdges(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly = cddm->mpoly;
int totpoly = dm->getNumPolys(dm);
int prevstart = 0;
bool prevdraw = true;
int curpos = 0;
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 i;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
GPU_uvedge_setup(dm);
for (i = 0; i < totpoly; i++, mpoly++) {
const bool draw = (mpoly->flag & ME_HIDE) == 0;
Minor simplification for uv edge drawing
2015-07-07 15:08:45 +10:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (prevdraw != draw) {
if (prevdraw && (curpos != prevstart)) {
glDrawArrays(GL_LINES, prevstart, curpos - prevstart);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
prevstart = curpos;
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 tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
curpos += 2 * mpoly->totloop;
prevdraw = draw;
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 tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (prevdraw && (curpos != prevstart)) {
glDrawArrays(GL_LINES, prevstart, curpos - prevstart);
}
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
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
}
Code cleanup: use bools for DM
2014-04-17 19:33:54 +10:00
static void cdDM_drawEdges(DerivedMesh *dm, bool drawLooseEdges, bool drawAllEdges)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Fix T45136, only draw edges if there's something to draw.
2015-06-22 15:18:04 +02:00
GPUDrawObject *gdo;
Use GPU_Buffers to draw wireframe when in dynamic-topology sculpt mode This adds an override to the CDDM edge drawing function that switches to GPU_Buffers drawing for PBVHes of type PBVH_BMESH. Within the GPU_Buffers code, glPolygonMode() is used to draw lines instead of faces.
2012-12-30 18:30:13 +00:00
if (cddm->pbvh && cddm->pbvh_draw &&
Style Cleanup: whitespace
2014-01-12 22:05:24 +11:00
BKE_pbvh_type(cddm->pbvh) == PBVH_BMESH)
Use GPU_Buffers to draw wireframe when in dynamic-topology sculpt mode This adds an override to the CDDM edge drawing function that switches to GPU_Buffers drawing for PBVHes of type PBVH_BMESH. Within the GPU_Buffers code, glPolygonMode() is used to draw lines instead of faces.
2012-12-30 18:30:13 +00:00
{
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
BKE_pbvh_draw(cddm->pbvh, NULL, NULL, NULL, true, false);
Use GPU_Buffers to draw wireframe when in dynamic-topology sculpt mode This adds an override to the CDDM edge drawing function that switches to GPU_Buffers drawing for PBVHes of type PBVH_BMESH. Within the GPU_Buffers code, glPolygonMode() is used to draw lines instead of faces.
2012-12-30 18:30:13 +00:00
return;
}
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
GPU_edge_setup(dm);
Fix T45136, only draw edges if there's something to draw.
2015-06-22 15:18:04 +02:00
gdo = dm->drawObject;
if (gdo->edges && gdo->points) {
if (drawAllEdges && drawLooseEdges) {
GPU_buffer_draw_elements(gdo->edges, GL_LINES, 0, gdo->totedge * 2);
}
else if (drawAllEdges) {
GPU_buffer_draw_elements(gdo->edges, GL_LINES, 0, gdo->loose_edge_offset * 2);
}
else {
GPU_buffer_draw_elements(gdo->edges, GL_LINES, 0, gdo->tot_edge_drawn * 2);
GPU_buffer_draw_elements(gdo->edges, GL_LINES, gdo->loose_edge_offset * 2, dm->drawObject->tot_loose_edge_drawn * 2);
}
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
}
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
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
}
static void cdDM_drawLooseEdges(DerivedMesh *dm)
{
Fix edge drawing, total loose edges can only be determined -after- the edge buffer has been setup (this is where they are counted)
2015-06-23 12:06:36 +02:00
int start;
int count;
GPU_edge_setup(dm);
start = (dm->drawObject->loose_edge_offset * 2);
count = (dm->drawObject->totedge - dm->drawObject->loose_edge_offset) * 2;
Fix T45117: Dark dupli-face objects (regression)
2015-06-23 08:02:00 +10:00
if (count) {
GPU_buffer_draw_elements(dm->drawObject->edges, GL_LINES, start, count);
}
Fix edge drawing, total loose edges can only be determined -after- the edge buffer has been setup (this is where they are counted)
2015-06-23 12:06:36 +02:00
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
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
}
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawFacesSolid(
DerivedMesh *dm,
float (*partial_redraw_planes)[4],
bool UNUSED(fast), DMSetMaterial setMaterial)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
int a;
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
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
if (cddm->pbvh) {
if (cddm->pbvh_draw && BKE_pbvh_has_faces(cddm->pbvh)) {
Fix T46899 sculpt normals not getting updated after exiting sculpt mode. Habit is a bad thing: Update polys, not tessfaces.
2015-12-03 00:13:45 +01:00
float (*face_nors)[3] = CustomData_get_layer(&dm->polyData, CD_NORMAL);
Sculpt: Multithreading & PBVH Changes * Sculpting, normal update and bounding box code is now multithreaded using OpenMP. * Fix a number of update issues: normals on node boundaries, outdated bounding boxes, partial redraw, .. . There's probably still a few left, but should be better now. * Clicking once now does a single paint instead of two (was also painting on mouse up event). * Smooth shading now is enabled for the full mesh when the first face uses it (so it can be tested at least). Implementation Notes: * PBVH search can now be done either using a callback or bt gathering the nodes in an array. The latter makes multithreading with OpenMP easier. * Normals update code is now inside PBVH, was doing it per node before but should do all faces first and only then vertices. * Instead of using search modes + 1 modified flag, now nodes get 4 flags to indicate what needs to be updated for them, found that this makes it easier for me to understand the code and fix update bugs. * PBVHNode is now exposed as an abstract type, I think this makes it more clear what is happening than having it's data passed as part of callback functions. * Active_verts list was replaced by looping over nodes and the vertices inside them. However the grab brush still uses the active_verts system, will fix that later. * Some micro-optimizations, like avoiding a few multiplications/divisions, using local variables instead of pointers, or looping over fewer vertices to update the bounding boxes.
2009-11-02 18:47:03 +00:00
Code cleanup: rename BLI_pbvh to BKE_pbvh
2012-12-30 18:31:31 +00:00
BKE_pbvh_draw(cddm->pbvh, partial_redraw_planes, face_nors,
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
setMaterial, false, false);
Fix part of #20468: material changes when switch to sculpt mode.
2010-02-06 17:04:13 +00:00
glShadeModel(GL_FLAT);
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
return;
}
Commit of the sculpt patch (#19672). Further development will be in this branch until we merge to trunk.
2009-10-27 19:53:34 +00:00
}
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
GPU_vertex_setup(dm);
GPU_normal_setup(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU_triangle_setup(dm);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
glShadeModel(GL_SMOOTH);
for (a = 0; a < dm->drawObject->totmaterial; a++) {
if (!setMaterial || setMaterial(dm->drawObject->materials[a].mat_nr + 1, NULL)) {
Cleanup: ws
2015-07-15 12:08:32 +10:00
GPU_buffer_draw_elements(
dm->drawObject->triangles, GL_TRIANGLES,
dm->drawObject->materials[a].start, dm->drawObject->materials[a].totelements);
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
}
}
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
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 with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
glShadeModel(GL_FLAT);
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
}
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawFacesTex_common(
DerivedMesh *dm,
DMSetDrawOptionsTex drawParams,
DMSetDrawOptionsMappedTex drawParamsMapped,
DMCompareDrawOptions compareDrawOptions,
void *userData, DMDrawFlag uvflag)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly = cddm->mpoly;
Move from MTFace to MTexPoly w/ texture checks Part of moving away from MFace.
2015-07-14 22:27:25 +10:00
MTexPoly *mtexpoly = DM_get_poly_data_layer(dm, CD_MTEXPOLY);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MLoopCol *mloopcol;
int i;
Fix overdrawing and errors with textured and mapped drawing
2015-07-14 23:48:38 +02:00
int colType, start_element, tot_drawn;
GSOC 2013 paint Yep, at last it's here! There are a few minor issues remaining but development can go on in master after discussion at blender institute. For full list of features see: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting Thanks to Sergey and Campbell for the extensive review and to the countless artists that have given their input and reported issues during development.
2014-07-21 12:02:05 +02:00
bool use_tface = (uvflag & DM_DRAW_USE_ACTIVE_UV) != 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int totpoly;
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
int next_actualFace;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int mat_index;
int tot_element;
Fix for own r51737. Refactoring of draw code showed another problem: The MCol we want to draw may change without dm rebuild (e.g. when enabling solid textured option)! Also, choosing which MCol layer to use in GPU code is stupid, different draw modes use different layers/order of precedence! Solved this by adding a new colType parameter to GPU_color_setup, and removing any 'color choosing' code from gpu_buffers.c.
2012-10-30 11:00:06 +00:00
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
/* double lookup */
const int *index_mp_to_orig = dm->getPolyDataArray(dm, CD_ORIGINDEX);
Workaround for textured display with dynamic topology enabled This will only make object display with proper shape in textured view, but all materials and textures will be replaced with default gray color. There's currently no better way to deal with textured display when dynamic topology enabled because of all UV/tfaces are clearing when enabling dynamic topology sculpt. Anyway, better to display gray object with proper lighting in this case rather than not update object's shape during sculpt. Proper solution will be possible once CD layer will be preserved by BMesh log.
2013-01-06 08:28:45 +00:00
/* TODO: not entirely correct, but currently dynamic topology will
* destroy UVs anyway, so textured display wouldn't work anyway
*
* this will do more like solid view with lights set up for
* textured view, but object itself will be displayed gray
* (the same as it'll display without UV maps in textured view)
*/
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
if (cddm->pbvh) {
if (cddm->pbvh_draw &&
BKE_pbvh_type(cddm->pbvh) == PBVH_BMESH &&
BKE_pbvh_has_faces(cddm->pbvh))
{
Fix #35354: dyntopo - materials and UI display issues Textured dyntopo draw was leaving 2d textures enabled when it shouldn't. Root of the issue was figured out by Campbell, actual place where 2D textures left enabled found by self. Also, simplified fix is suggested by Campbell (mine was 2 lines longer! :)
2013-05-15 12:33:28 +00:00
GPU_set_tpage(NULL, false, false);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
BKE_pbvh_draw(cddm->pbvh, NULL, NULL, NULL, false, false);
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
return;
}
else {
cdDM_update_normals_from_pbvh(dm);
Workaround for textured display with dynamic topology enabled This will only make object display with proper shape in textured view, but all materials and textures will be replaced with default gray color. There's currently no better way to deal with textured display when dynamic topology enabled because of all UV/tfaces are clearing when enabling dynamic topology sculpt. Anyway, better to display gray object with proper lighting in this case rather than not update object's shape during sculpt. Proper solution will be possible once CD layer will be preserved by BMesh log.
2013-01-06 08:28:45 +00:00
}
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
colType = CD_TEXTURE_MLOOPCOL;
mloopcol = dm->getLoopDataArray(dm, colType);
if (!mloopcol) {
Use loop data instead of face data Replace checks in various places
2015-07-27 20:59:10 +10:00
colType = CD_PREVIEW_MLOOPCOL;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
mloopcol = dm->getLoopDataArray(dm, colType);
Fix for own r51737. Refactoring of draw code showed another problem: The MCol we want to draw may change without dm rebuild (e.g. when enabling solid textured option)! Also, choosing which MCol layer to use in GPU code is stupid, different draw modes use different layers/order of precedence! Solved this by adding a new colType parameter to GPU_color_setup, and removing any 'color choosing' code from gpu_buffers.c.
2012-10-30 11:00:06 +00:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (!mloopcol) {
colType = CD_MLOOPCOL;
mloopcol = dm->getLoopDataArray(dm, colType);
Fix for own r51737. Refactoring of draw code showed another problem: The MCol we want to draw may change without dm rebuild (e.g. when enabling solid textured option)! Also, choosing which MCol layer to use in GPU code is stupid, different draw modes use different layers/order of precedence! Solved this by adding a new colType parameter to GPU_color_setup, and removing any 'color choosing' code from gpu_buffers.c.
2012-10-30 11:00:06 +00:00
}
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
GPU_vertex_setup(dm);
GPU_normal_setup(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU_triangle_setup(dm);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
if (uvflag & DM_DRAW_USE_TEXPAINT_UV)
GPU_texpaint_uv_setup(dm);
else
GPU_uv_setup(dm);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (mloopcol) {
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
GPU_color_setup(dm, colType);
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
glShadeModel(GL_SMOOTH);
/* lastFlag = 0; */ /* UNUSED */
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (mat_index = 0; mat_index < dm->drawObject->totmaterial; mat_index++) {
GPUBufferMaterial *bufmat = dm->drawObject->materials + mat_index;
next_actualFace = bufmat->polys[0];
totpoly = bufmat->totpolys;
tot_element = 0;
Fix overdrawing and errors with textured and mapped drawing
2015-07-14 23:48:38 +02:00
tot_drawn = 0;
start_element = 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (i = 0; i < totpoly; i++) {
int actualFace = bufmat->polys[i];
DMDrawOption draw_option = DM_DRAW_OPTION_NORMAL;
int flush = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int tot_tri_verts;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (i != totpoly - 1)
next_actualFace = bufmat->polys[i + 1];
if (drawParams) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
MTexPoly *tp = use_tface && mtexpoly ? &mtexpoly[actualFace] : NULL;
draw_option = drawParams(tp, (mloopcol != NULL), mpoly[actualFace].mat_nr);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
else {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (index_mp_to_orig) {
const int orig = index_mp_to_orig[actualFace];
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (orig == ORIGINDEX_NONE) {
/* XXX, this is not really correct
* it will draw the previous faces context for this one when we don't know its settings.
* but better then skipping it altogether. - campbell */
draw_option = DM_DRAW_OPTION_NORMAL;
}
else if (drawParamsMapped) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
draw_option = drawParamsMapped(userData, orig, mpoly[actualFace].mat_nr);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
fix [#33394] Skin modifier doesn't show generated skin mesh in EditMode with Texured Solid draw option
2012-12-03 09:08:53 +00:00
}
else if (drawParamsMapped) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
draw_option = drawParamsMapped(userData, actualFace, mpoly[actualFace].mat_nr);
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
/* flush buffer if current triangle isn't drawable or it's last triangle */
flush = (draw_option == DM_DRAW_OPTION_SKIP) || (i == totpoly - 1);
if (!flush && compareDrawOptions) {
/* also compare draw options and flush buffer if they're different
* need for face selection highlight in edit mode */
flush |= compareDrawOptions(userData, actualFace, next_actualFace) == 0;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_tri_verts = ME_POLY_TRI_TOT(&mpoly[actualFace]) * 3;
tot_element += tot_tri_verts;
Fix overdrawing and errors with textured and mapped drawing
2015-07-14 23:48:38 +02:00
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (flush) {
if (draw_option != DM_DRAW_OPTION_SKIP)
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_drawn += tot_tri_verts;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Fix overdrawing and errors with textured and mapped drawing
2015-07-14 23:48:38 +02:00
if (tot_drawn) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (mloopcol && draw_option != DM_DRAW_OPTION_NO_MCOL)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU_color_switch(1);
else
GPU_color_switch(0);
Fix overdrawing and errors with textured and mapped drawing
2015-07-14 23:48:38 +02:00
GPU_buffer_draw_elements(dm->drawObject->triangles, GL_TRIANGLES, bufmat->start + start_element, tot_drawn);
tot_drawn = 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
start_element = tot_element;
}
else {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_drawn += tot_tri_verts;
dont use tface hide or select anymore, since maintaining 2 sets of hide/select data for each face is annoying. using mface->flag for both. Also found that the cdDM_drawMappedFaces and cdDM_drawFacesTex_common could get normals mixed up when rendering hidden faces. because hidden/invisible faces used continue without advancing to the next normal.
2007-04-29 13:39:46 +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
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
glShadeModel(GL_FLAT);
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
}
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawFacesTex(
DerivedMesh *dm,
DMSetDrawOptionsTex setDrawOptions,
DMCompareDrawOptions compareDrawOptions,
void *userData, DMDrawFlag uvflag)
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
{
GSOC 2013 paint Yep, at last it's here! There are a few minor issues remaining but development can go on in master after discussion at blender institute. For full list of features see: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting Thanks to Sergey and Campbell for the extensive review and to the countless artists that have given their input and reported issues during development.
2014-07-21 12:02:05 +02:00
cdDM_drawFacesTex_common(dm, setDrawOptions, NULL, compareDrawOptions, userData, uvflag);
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
}
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawMappedFaces(
DerivedMesh *dm,
DMSetDrawOptions setDrawOptions,
DMSetMaterial setMaterial,
DMCompareDrawOptions compareDrawOptions,
void *userData, DMDrawFlag flag)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly = cddm->mpoly;
const MLoopCol *mloopcol = NULL;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
int colType, useColors = flag & DM_DRAW_USE_COLORS, useHide = flag & DM_DRAW_SKIP_HIDDEN;
Avoid getting the original index if its not needed
2015-07-18 04:57:58 +10:00
int i, j;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
int start_element = 0, tot_element, tot_drawn;
int totpoly;
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
int tot_tri_elem;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
int mat_index;
GPUBuffer *findex_buffer = NULL;
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
const int *index_mp_to_orig = dm->getPolyDataArray(dm, CD_ORIGINDEX);
Fixed bug #23922, Sculpting - Textured display draws incorrectly Root cause is that some drawing modes don't work with PBVH drawing. Worked around by adding a call to update mesh normals from the PBVH so that sculpted changes appear correctly in those "unsupported" modes. (They'll still draw much more slowly than solid, but should at least appear correct now.)
2010-12-14 03:30:30 +00:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
/* fist, setup common buffers */
GPU_vertex_setup(dm);
GPU_triangle_setup(dm);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
totpoly = dm->getNumPolys(dm);
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
/* if we do selection, fill the selection buffer color */
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
if (G.f & G_BACKBUFSEL) {
if (!(flag & DM_DRAW_SKIP_SELECT)) {
Fix T45605 crash with editmode selection on solidify modifier. Looks like derivedmesh draw code always assumed a mesh is available. Make sure that if we use a bmesh, a flag is used to control that.
2015-07-29 16:18:33 +02:00
Mesh *me = NULL;
BMesh *bm = NULL;
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
unsigned int *fi_map;
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
Fix T45605 crash with editmode selection on solidify modifier. Looks like derivedmesh draw code always assumed a mesh is available. Make sure that if we use a bmesh, a flag is used to control that.
2015-07-29 16:18:33 +02:00
if (flag & DM_DRAW_SELECT_USE_EDITMODE)
bm = userData;
else
me = userData;
Remove vertex array support from GPUBuffers. Remove USER_DISABLE_VBO. All GPUBuffer rendering is now done using vertex buffers. Vertex arrays are completely removed from GL 3.2 core profile, so we'll have to do this change at some point anyway. This commit, though big, is not modifying blender in any way. Use should be exactly as if the vetex buffer option is constantly on.
2015-11-22 19:46:31 +01:00
findex_buffer = GPU_buffer_alloc(dm->drawObject->tot_loop_verts * sizeof(int));
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
fi_map = GPU_buffer_lock(findex_buffer, GPU_BINDING_ARRAY);
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
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
if (fi_map) {
for (i = 0; i < totpoly; i++, mpoly++) {
int selcol = 0xFFFFFFFF;
const int orig = (index_mp_to_orig) ? index_mp_to_orig[i] : i;
Fix T45605 crash with editmode selection on solidify modifier. Looks like derivedmesh draw code always assumed a mesh is available. Make sure that if we use a bmesh, a flag is used to control that.
2015-07-29 16:18:33 +02:00
bool is_hidden;
if (useHide) {
if (flag & DM_DRAW_SELECT_USE_EDITMODE) {
BMFace *efa = BM_face_at_index(bm, orig);
is_hidden = BM_elem_flag_test(efa, BM_ELEM_HIDDEN) != 0;
}
else {
is_hidden = (me->mpoly[orig].flag & ME_HIDE) != 0;
}
if ((orig != ORIGINDEX_NONE) && !is_hidden)
WM_framebuffer_index_get(orig + 1, &selcol);
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
}
Fix T45605 crash with editmode selection on solidify modifier. Looks like derivedmesh draw code always assumed a mesh is available. Make sure that if we use a bmesh, a flag is used to control that.
2015-07-29 16:18:33 +02:00
else if (orig != ORIGINDEX_NONE)
WM_framebuffer_index_get(orig + 1, &selcol);
Fix part of #34882: mesh active face not drawing stippled with the mirror modifier.
2013-04-22 21:12:11 +00:00
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
for (j = 0; j < mpoly->totloop; j++)
fi_map[start_element++] = selcol;
}
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
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
start_element = 0;
mpoly = cddm->mpoly;
Fix part of #34882: mesh active face not drawing stippled with the mirror modifier.
2013-04-22 21:12:11 +00:00
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
GPU_buffer_unlock(findex_buffer, GPU_BINDING_ARRAY);
GPU_buffer_bind_as_color(findex_buffer);
}
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
}
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
else {
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
GPU_normal_setup(dm);
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
if (useColors) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
colType = CD_TEXTURE_MLOOPCOL;
mloopcol = DM_get_loop_data_layer(dm, colType);
if (!mloopcol) {
colType = CD_PREVIEW_MLOOPCOL;
mloopcol = DM_get_loop_data_layer(dm, colType);
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (!mloopcol) {
colType = CD_MLOOPCOL;
mloopcol = DM_get_loop_data_layer(dm, colType);
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (useColors && mloopcol) {
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
GPU_color_setup(dm, colType);
}
Complete fix for [#33002] Wrong vertex color. Appart from the color glitch, there was several problems with vpaint: * "fast_update" mode was never on, because of wrong testing code; * drawing refresh during stroke in "fast_update" (i.e. no dm rebuild) mode was broken in VBO mode, because updated (tess data) mcol wasn't moved to colors GPUBuffer. Solved the later point by adding a new DM_DIRTY_MCOL_UPDATE_DRAW flag to DerivedMesh dirty var, which is set each time vpaint stroke directly update me->mcol, and forces GPU_color_setup() to refresh the gpu's colors buffer. Also got rid of the uggly GPU_color3_upload(), which basically did the same thing, but with an additional intermediate buffer !
2012-10-29 16:26:18 +00:00
}
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
}
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
glShadeModel(GL_SMOOTH);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
tot_tri_elem = dm->drawObject->tot_triangle_point;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
if (tot_tri_elem == 0) {
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
/* avoid buffer problems in following code */
}
else if (setDrawOptions == NULL) {
/* just draw the entire face array */
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
GPU_buffer_draw_elements(dm->drawObject->triangles, GL_TRIANGLES, 0, tot_tri_elem);
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
}
else {
for (mat_index = 0; mat_index < dm->drawObject->totmaterial; mat_index++) {
GPUBufferMaterial *bufmat = dm->drawObject->materials + mat_index;
DMDrawOption draw_option = DM_DRAW_OPTION_NORMAL;
int next_actualFace = bufmat->polys[0];
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
totpoly = useHide ? bufmat->totvisiblepolys : bufmat->totpolys;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
tot_element = 0;
start_element = 0;
tot_drawn = 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
if (setMaterial)
draw_option = setMaterial(bufmat->mat_nr + 1, NULL);
if (draw_option != DM_DRAW_OPTION_SKIP) {
cdderivedmesh fix stippled faces not getting drawn at all Also rearranged code here to not issue a draw call (explicit flush) per face and not set shader per face either when stippled drawing is mixed with regular drawing. Not good at all for performance.
2015-12-28 17:54:45 +01:00
DMDrawOption last_draw_option = DM_DRAW_OPTION_NORMAL;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
for (i = 0; i < totpoly; i++) {
int actualFace = next_actualFace;
int flush = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int tot_tri_verts;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
draw_option = DM_DRAW_OPTION_NORMAL;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
if (i != totpoly - 1)
next_actualFace = bufmat->polys[i + 1];
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Avoid getting the original index if its not needed
2015-07-18 04:57:58 +10:00
if (setDrawOptions) {
const int orig = (index_mp_to_orig) ? index_mp_to_orig[actualFace] : actualFace;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Avoid getting the original index if its not needed
2015-07-18 04:57:58 +10:00
if (orig != ORIGINDEX_NONE) {
draw_option = setDrawOptions(userData, orig);
}
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
/* Goal is to draw as long of a contiguous triangle
* array as possible, so draw when we hit either an
* invisible triangle or at the end of the array */
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
/* flush buffer if current triangle isn't drawable or it's last triangle... */
cdderivedmesh fix stippled faces not getting drawn at all Also rearranged code here to not issue a draw call (explicit flush) per face and not set shader per face either when stippled drawing is mixed with regular drawing. Not good at all for performance.
2015-12-28 17:54:45 +01:00
flush = (draw_option != last_draw_option) || (i == totpoly - 1);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
if (!flush && compareDrawOptions) {
flush |= compareDrawOptions(userData, actualFace, next_actualFace) == 0;
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_tri_verts = ME_POLY_TRI_TOT(&mpoly[actualFace]) * 3;
tot_element += tot_tri_verts;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
if (flush) {
cdderivedmesh fix stippled faces not getting drawn at all Also rearranged code here to not issue a draw call (explicit flush) per face and not set shader per face either when stippled drawing is mixed with regular drawing. Not good at all for performance.
2015-12-28 17:54:45 +01:00
if (draw_option != DM_DRAW_OPTION_SKIP) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_drawn += tot_tri_verts;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
cdderivedmesh fix stippled faces not getting drawn at all Also rearranged code here to not issue a draw call (explicit flush) per face and not set shader per face either when stippled drawing is mixed with regular drawing. Not good at all for performance.
2015-12-28 17:54:45 +01:00
if (last_draw_option != draw_option) {
if (draw_option == DM_DRAW_OPTION_STIPPLE) {
GPU_basic_shader_bind(GPU_SHADER_STIPPLE | GPU_SHADER_USE_COLOR);
GPU_basic_shader_stipple(GPU_SHADER_STIPPLE_QUARTTONE);
}
else {
GPU_basic_shader_bind(GPU_SHADER_USE_COLOR);
}
}
}
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
if (tot_drawn) {
GPU_buffer_draw_elements(dm->drawObject->triangles, GL_TRIANGLES, bufmat->start + start_element, tot_drawn);
tot_drawn = 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
cdderivedmesh fix stippled faces not getting drawn at all Also rearranged code here to not issue a draw call (explicit flush) per face and not set shader per face either when stippled drawing is mixed with regular drawing. Not good at all for performance.
2015-12-28 17:54:45 +01:00
last_draw_option = draw_option;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
start_element = tot_element;
}
else {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_drawn += tot_tri_verts;
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
}
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +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
}
}
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
cdderivedmesh fix stippled faces not getting drawn at all Also rearranged code here to not issue a draw call (explicit flush) per face and not set shader per face either when stippled drawing is mixed with regular drawing. Not good at all for performance.
2015-12-28 17:54:45 +01:00
GPU_basic_shader_bind(GPU_SHADER_USE_COLOR);
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
glShadeModel(GL_FLAT);
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
cdderivedmesh: don't prepare a normal buffer when selecting, even if we skip creating the selection color layer.
2015-07-28 18:23:59 +02:00
if (findex_buffer)
VBO offscreen selection drawing, cdderivedmesh Get rid of legacy drawing, it's only used for selection, in which case we can prepare a temporary color buffer and draw at once. Code is not complete here because we still redundantly set the draw color in the draw function and don't ommit hidden faces automatically. Still it works 100% without immediate mode now.
2015-07-15 18:50:02 +02:00
GPU_buffer_free(findex_buffer);
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
}
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawMappedFacesTex(
DerivedMesh *dm,
DMSetDrawOptionsMappedTex setDrawOptions,
DMCompareDrawOptions compareDrawOptions,
void *userData, DMDrawFlag flag)
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
{
GSOC 2013 paint Yep, at last it's here! There are a few minor issues remaining but development can go on in master after discussion at blender institute. For full list of features see: http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.72/Painting Thanks to Sergey and Campbell for the extensive review and to the countless artists that have given their input and reported issues during development.
2014-07-21 12:02:05 +02:00
cdDM_drawFacesTex_common(dm, NULL, setDrawOptions, compareDrawOptions, userData, flag);
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 tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
static void cddm_draw_attrib_vertex(
DMVertexAttribs *attribs, const MVert *mvert, int a, int index, int loop, int vert,
const float *lnor, const bool smoothnormal)
Code cleanup: small glsl mesh drawing code changes, getting rid of an ugly macro.
2011-08-12 18:17:28 +00:00
{
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
DM_draw_attrib_vertex(attribs, a, index, vert, loop);
Code cleanup: small glsl mesh drawing code changes, getting rid of an ugly macro.
2011-08-12 18:17:28 +00:00
/* vertex normal */
Split Normals I (3/5): Add 3Dview shading support of split normals. Mostly monkey coding in gpu ("modern" VBO drawing) and DM variants ("legacy" drawing) code... Reviewers: brecht Reviewed By: brecht CC: campbellbarton Differential Revision: https://developer.blender.org/D367
2014-04-13 12:29:21 +02:00
if (lnor) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
glNormal3fv(lnor);
Split Normals I (3/5): Add 3Dview shading support of split normals. Mostly monkey coding in gpu ("modern" VBO drawing) and DM variants ("legacy" drawing) code... Reviewers: brecht Reviewed By: brecht CC: campbellbarton Differential Revision: https://developer.blender.org/D367
2014-04-13 12:29:21 +02:00
}
else if (smoothnormal) {
Code cleanup: small glsl mesh drawing code changes, getting rid of an ugly macro.
2011-08-12 18:17:28 +00:00
glNormal3sv(mvert[index].no);
Split Normals I (3/5): Add 3Dview shading support of split normals. Mostly monkey coding in gpu ("modern" VBO drawing) and DM variants ("legacy" drawing) code... Reviewers: brecht Reviewed By: brecht CC: campbellbarton Differential Revision: https://developer.blender.org/D367
2014-04-13 12:29:21 +02:00
}
Code cleanup: small glsl mesh drawing code changes, getting rid of an ugly macro.
2011-08-12 18:17:28 +00:00
/* vertex coordinate */
glVertex3fv(mvert[index].co);
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
typedef struct {
DMVertexAttribs attribs;
int numdata;
GPUAttrib datatypes[GPU_MAX_ATTRIB]; /* TODO, messing up when switching materials many times - [#21056]*/
} GPUMaterialConv;
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawMappedFacesGLSL(
DerivedMesh *dm,
DMSetMaterial setMaterial,
DMSetDrawOptions setDrawOptions,
void *userData)
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
GPUVertexAttribs gattribs;
Cleanup: use const for read-only arrays
2014-09-18 15:14:25 +10:00
const MVert *mvert = cddm->mvert;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly = cddm->mpoly;
const MLoop *mloop = cddm->mloop;
const MLoopTri *lt = dm->getLoopTriArray(dm);
const int tottri = dm->getNumLoopTri(dm);
svn merge ^/trunk/blender -r40372:40379
2011-09-23 06:18:03 +00:00
/* MTFace *tf = dm->getTessFaceDataArray(dm, CD_MTFACE); */ /* UNUSED */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const float (*nors)[3] = dm->getPolyDataArray(dm, CD_NORMAL);
const float (*lnors)[3] = dm->getLoopDataArray(dm, CD_NORMAL);
const int totpoly = dm->getNumPolys(dm);
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
const short dm_totmat = dm->totmat;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
int a, b, matnr, new_matnr;
bool do_draw;
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
int orig;
const int *index_mp_to_orig = dm->getPolyDataArray(dm, CD_ORIGINDEX);
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
Fix/workaround for GLSL textured and matcap modes for dyntopo Currently used special checks in DM draw code, perhaps better would be simply to flush changes from PBVH to DM. Anyway, now things seems to be working OK, will check on better solution from code point of view later.
2013-01-22 16:06:09 +00:00
/* TODO: same as for solid draw, not entirely correct, but works fine for now,
* will skip using textures (dyntopo currently destroys UV anyway) and
* works fine for matcap
*/
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
if (cddm->pbvh) {
if (cddm->pbvh_draw &&
BKE_pbvh_type(cddm->pbvh) == PBVH_BMESH &&
BKE_pbvh_has_faces(cddm->pbvh))
{
Fix/workaround for GLSL textured and matcap modes for dyntopo Currently used special checks in DM draw code, perhaps better would be simply to flush changes from PBVH to DM. Anyway, now things seems to be working OK, will check on better solution from code point of view later.
2013-01-22 16:06:09 +00:00
setMaterial(1, &gattribs);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
BKE_pbvh_draw(cddm->pbvh, NULL, NULL, NULL, false, false);
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
return;
}
else {
cdDM_update_normals_from_pbvh(dm);
Fix/workaround for GLSL textured and matcap modes for dyntopo Currently used special checks in DM draw code, perhaps better would be simply to flush changes from PBVH to DM. Anyway, now things seems to be working OK, will check on better solution from code point of view later.
2013-01-22 16:06:09 +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
matnr = -1;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
do_draw = false;
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
glShadeModel(GL_SMOOTH);
Cleanup: whitespace
2015-11-26 11:08:25 +11:00
if (setDrawOptions != NULL) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
DMVertexAttribs attribs;
style cleanup: function calls & whitespace.
2012-04-29 17:11:40 +00:00
DEBUG_VBO("Using legacy code. cdDM_drawMappedFacesGLSL\n");
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
memset(&attribs, 0, sizeof(attribs));
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
glBegin(GL_TRIANGLES);
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
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (a = 0; a < tottri; a++, lt++) {
const MPoly *mp = &mpoly[lt->poly];
const unsigned int vtri[3] = {mloop[lt->tri[0]].v, mloop[lt->tri[1]].v, mloop[lt->tri[2]].v};
const unsigned int *ltri = lt->tri;
const float *ln1 = NULL, *ln2 = NULL, *ln3 = NULL;
const bool smoothnormal = lnors || (mp->flag & ME_SMOOTH);
new_matnr = mp->mat_nr;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (new_matnr != matnr) {
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
glEnd();
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
Fix GLSL code not working correctly for Macs without VBO, again report by scorpion81 on irc
2015-07-17 19:12:04 +02:00
matnr = new_matnr;
do_draw = setMaterial(matnr + 1, &gattribs);
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
if (do_draw)
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
DM_vertex_attributes_from_gpu(dm, &gattribs, &attribs);
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
Fix T45465 Easy one, we don't draw quads anymore. Also normal didn't use polygon index
2015-07-17 13:24:01 +02:00
glBegin(GL_TRIANGLES);
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
code cleanup: use TRUE/FALSE rather then 1/0 for better readability, also replace do prefix with do_ for bool vars.
2012-05-19 13:28:19 +00:00
if (!do_draw) {
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
continue;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
else if (setDrawOptions) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
orig = (index_mp_to_orig) ? index_mp_to_orig[lt->poly] : lt->poly;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (orig == ORIGINDEX_NONE) {
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
/* since the material is set by setMaterial(), faces with no
* origin can be assumed to be generated by a modifier */
/* continue */
}
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
else if (setDrawOptions(userData, orig) == DM_DRAW_OPTION_SKIP)
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
continue;
}
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!smoothnormal) {
if (nors) {
Fix T45465 Easy one, we don't draw quads anymore. Also normal didn't use polygon index
2015-07-17 13:24:01 +02:00
glNormal3fv(nors[lt->poly]);
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
else {
/* TODO ideally a normal layer should always be available */
float nor[3];
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
normal_tri_v3(nor, mvert[vtri[0]].co, mvert[vtri[1]].co, mvert[vtri[2]].co);
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
glNormal3fv(nor);
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
}
}
Fix T41862: Autosmooth & multi-material glitch
2014-09-18 14:55:33 +10:00
else if (lnors) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
ln1 = lnors[ltri[0]];
ln2 = lnors[ltri[1]];
ln3 = lnors[ltri[2]];
Split Normals I (3/5): Add 3Dview shading support of split normals. Mostly monkey coding in gpu ("modern" VBO drawing) and DM variants ("legacy" drawing) code... Reviewers: brecht Reviewed By: brecht CC: campbellbarton Differential Revision: https://developer.blender.org/D367
2014-04-13 12:29:21 +02:00
}
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
cddm_draw_attrib_vertex(&attribs, mvert, a, vtri[0], ltri[0], 0, ln1, smoothnormal);
cddm_draw_attrib_vertex(&attribs, mvert, a, vtri[1], ltri[1], 1, ln2, smoothnormal);
cddm_draw_attrib_vertex(&attribs, mvert, a, vtri[2], ltri[2], 2, ln3, smoothnormal);
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
glEnd();
}
else {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPUMaterialConv *matconv;
int offset;
int *mat_orig_to_new;
int tot_active_mat;
fix for warnings from Sparse static source code checker, mostly BKE/BLI and python functions. - use NULL rather then 0 where possible (makes code & function calls more readable IMHO). - set static variables and functions (exposed some unused vars/funcs). - use func(void) rather then func() for definitions.
2011-02-13 10:52:18 +00:00
GPUBuffer *buffer = NULL;
Fix warnings and remove casts by adding copy_vx_vx_uchar() functions.
2015-10-11 01:44:47 +02:00
unsigned char *varray;
Fix no longer being possible to display a suzanne with 8 levels of subdivision. Classic integet overflow/size_t substitution case. Machines are getting powerful enough to easily expose these kinds of error now.
2015-07-17 12:25:05 +02:00
size_t max_element_size = 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int tot_loops = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
GPU_vertex_setup(dm);
GPU_normal_setup(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU_triangle_setup(dm);
tot_active_mat = dm->drawObject->totmaterial;
matconv = MEM_callocN(sizeof(*matconv) * tot_active_mat,
"cdDM_drawMappedFacesGLSL.matconv");
mat_orig_to_new = MEM_mallocN(sizeof(*mat_orig_to_new) * dm->totmat,
"cdDM_drawMappedFacesGLSL.mat_orig_to_new");
/* part one, check what attributes are needed per material */
for (a = 0; a < tot_active_mat; a++) {
new_matnr = dm->drawObject->materials[a].mat_nr;
/* map from original material index to new
* GPUBufferMaterial index */
mat_orig_to_new[new_matnr] = a;
do_draw = setMaterial(new_matnr + 1, &gattribs);
if (do_draw) {
int numdata = 0;
DM_vertex_attributes_from_gpu(dm, &gattribs, &matconv[a].attribs);
if (matconv[a].attribs.totorco && matconv[a].attribs.orco.array) {
matconv[a].datatypes[numdata].index = matconv[a].attribs.orco.gl_index;
matconv[a].datatypes[numdata].size = 3;
matconv[a].datatypes[numdata].type = GL_FLOAT;
numdata++;
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (b = 0; b < matconv[a].attribs.tottface; b++) {
if (matconv[a].attribs.tface[b].array) {
matconv[a].datatypes[numdata].index = matconv[a].attribs.tface[b].gl_index;
matconv[a].datatypes[numdata].size = 2;
matconv[a].datatypes[numdata].type = GL_FLOAT;
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
numdata++;
}
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (b = 0; b < matconv[a].attribs.totmcol; b++) {
if (matconv[a].attribs.mcol[b].array) {
matconv[a].datatypes[numdata].index = matconv[a].attribs.mcol[b].gl_index;
matconv[a].datatypes[numdata].size = 4;
matconv[a].datatypes[numdata].type = GL_UNSIGNED_BYTE;
numdata++;
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
}
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (matconv[a].attribs.tottang && matconv[a].attribs.tang.array) {
matconv[a].datatypes[numdata].index = matconv[a].attribs.tang.gl_index;
matconv[a].datatypes[numdata].size = 4;
matconv[a].datatypes[numdata].type = GL_FLOAT;
numdata++;
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (numdata != 0) {
matconv[a].numdata = numdata;
max_element_size = max_ii(GPU_attrib_element_size(matconv[a].datatypes, numdata), max_element_size);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
}
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
/* part two, generate and fill the arrays with the data */
if (max_element_size > 0) {
Remove vertex array support from GPUBuffers. Remove USER_DISABLE_VBO. All GPUBuffer rendering is now done using vertex buffers. Vertex arrays are completely removed from GL 3.2 core profile, so we'll have to do this change at some point anyway. This commit, though big, is not modifying blender in any way. Use should be exactly as if the vetex buffer option is constantly on.
2015-11-22 19:46:31 +01:00
buffer = GPU_buffer_alloc(max_element_size * dm->drawObject->tot_loop_verts);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Sculpt draw code: Remove legacy code completely, now dyntopo, multires et al even work on GL 1.1 for really hardcore users :p Real purpose here though is to be able to have fast multires drawing even with VBO off, since it requires using indices for vertex buffers. Also made own code elf puke an eaten normal update function which made multires not update normals in solid mode...sorry.
2015-07-16 16:22:28 +02:00
varray = GPU_buffer_lock_stream(buffer, GPU_BINDING_ARRAY);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (varray == NULL) {
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU_buffer_free(buffer);
MEM_freeN(mat_orig_to_new);
MEM_freeN(matconv);
fprintf(stderr, "Out of memory, can't draw object\n");
return;
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (a = 0; a < totpoly; a++, mpoly++) {
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
const short mat_nr = ME_MAT_NR_TEST(mpoly->mat_nr, dm_totmat);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int j;
Fix T46073: crash w/ out-of-bounds material
2015-09-16 07:39:23 +10:00
int i = mat_orig_to_new[mat_nr];
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
offset = tot_loops * max_element_size;
if (matconv[i].numdata != 0) {
if (matconv[i].attribs.totorco && matconv[i].attribs.orco.array) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (j = 0; j < mpoly->totloop; j++)
copy_v3_v3((float *)&varray[offset + j * max_element_size],
(float *)matconv[i].attribs.orco.array[mloop[mpoly->loopstart + j].v]);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
offset += sizeof(float) * 3;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (b = 0; b < matconv[i].attribs.tottface; b++) {
if (matconv[i].attribs.tface[b].array) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MLoopUV *mloopuv = matconv[i].attribs.tface[b].array;
for (j = 0; j < mpoly->totloop; j++)
copy_v2_v2((float *)&varray[offset + j * max_element_size], mloopuv[mpoly->loopstart + j].uv);
Fix #37109: missing cycles texture display in edit mode. My previous fix for uninitialized texture coordinates was not working well, and in fact there was a bigger issue with GLSL drawing and missing attributes with immediate draw mode. Now it will explicitly pass zero rather than having it use whatever value was set last.
2013-10-17 14:04:10 +00:00
offset += sizeof(float) * 2;
}
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (b = 0; b < matconv[i].attribs.totmcol; b++) {
if (matconv[i].attribs.mcol[b].array) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MLoopCol *mloopcol = matconv[i].attribs.mcol[b].array;
for (j = 0; j < mpoly->totloop; j++)
Fix warnings and remove casts by adding copy_vx_vx_uchar() functions.
2015-10-11 01:44:47 +02:00
copy_v4_v4_uchar(&varray[offset + j * max_element_size], &mloopcol[mpoly->loopstart + j].r);
Fix #37109: missing cycles texture display in edit mode. My previous fix for uninitialized texture coordinates was not working well, and in fact there was a bigger issue with GLSL drawing and missing attributes with immediate draw mode. Now it will explicitly pass zero rather than having it use whatever value was set last.
2013-10-17 14:04:10 +00:00
offset += sizeof(unsigned char) * 4;
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (matconv[i].attribs.tottang && matconv[i].attribs.tang.array) {
Fix T46305: normal map display issues in viewport when using VBOs.
2015-10-05 00:10:28 +02:00
const float (*looptang)[4] = (const float (*)[4])matconv[i].attribs.tang.array;
for (j = 0; j < mpoly->totloop; j++)
copy_v4_v4((float *)&varray[offset + j * max_element_size], looptang[mpoly->loopstart + j]);
offset += sizeof(float) * 4;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_loops += mpoly->totloop;
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
Sculpt draw code: Remove legacy code completely, now dyntopo, multires et al even work on GL 1.1 for really hardcore users :p Real purpose here though is to be able to have fast multires drawing even with VBO off, since it requires using indices for vertex buffers. Also made own code elf puke an eaten normal update function which made multires not update normals in solid mode...sorry.
2015-07-16 16:22:28 +02:00
GPU_buffer_unlock(buffer, GPU_BINDING_ARRAY);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (a = 0; a < tot_active_mat; a++) {
new_matnr = dm->drawObject->materials[a].mat_nr;
do_draw = setMaterial(new_matnr + 1, &gattribs);
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01:00
if (do_draw) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (matconv[a].numdata) {
GPU_interleaved_attrib_setup(buffer, matconv[a].datatypes, matconv[a].numdata, max_element_size);
}
GPU_buffer_draw_elements(dm->drawObject->triangles, GL_TRIANGLES,
dm->drawObject->materials[a].start, dm->drawObject->materials[a].totelements);
if (matconv[a].numdata) {
GPU_interleaved_attrib_unbind();
merge with trunk/2.5 at r23876 [[Split portion of a mixed commit.]]
2009-10-22 23:22:05 +00:00
}
}
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Use abstraction to unbind buffers, should avoid crashes in systems that don't support VBOs. Exposed by initialization error in GLEW, which should be fixed seperately.
2015-07-20 12:12:28 +02:00
GPU_buffers_unbind();
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
if (buffer)
GPU_buffer_free(buffer);
MEM_freeN(mat_orig_to_new);
MEM_freeN(matconv);
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
}
Cleanup GPU: get rid of some extremely legacy draw code. Basically this commit gets rid of most of the derived mesh immediate mode drawing (cases such as subsurf excluded). Even when VBO is turned off in user preferences, we still use vertex arrays, which are very similar to VBOs but memory is client side. Vertex arrays are OpenGL 1.1 so compatibility is not an issue here. Reviewers: campbellbarton, sergey, jwilkins Differential Revision: https://developer.blender.org/D919
2014-11-28 14:38:18 +01: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
glShadeModel(GL_FLAT);
}
Code cleanup: use typedefs for DerivedMesh drawing callbacks. There are still fairly bewildering set of callbacks being tossed around, but it's at least a little less verbose now.
2012-03-07 04:41:14 +00:00
static void cdDM_drawFacesGLSL(DerivedMesh *dm, DMSetMaterial setMaterial)
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
{
dm->drawMappedFacesGLSL(dm, setMaterial, NULL, NULL);
}
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void cdDM_drawMappedFacesMat(
DerivedMesh *dm,
void (*setMaterial)(void *userData, int matnr, void *attribs),
bool (*setFace)(void *userData, int index), void *userData)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
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
GPUVertexAttribs gattribs;
DMVertexAttribs attribs;
MVert *mvert = cddm->mvert;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly = cddm->mpoly;
const MLoop *mloop = cddm->mloop;
const MLoopTri *lt = dm->getLoopTriArray(dm);
const int tottri = dm->getNumLoopTri(dm);
const float (*nors)[3] = dm->getPolyDataArray(dm, CD_NORMAL);
const float (*lnors)[3] = dm->getLoopDataArray(dm, CD_NORMAL);
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
int a, matnr, new_matnr;
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
int orig;
const int *index_mp_to_orig = dm->getPolyDataArray(dm, CD_ORIGINDEX);
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
Fix/workaround for GLSL textured and matcap modes for dyntopo Currently used special checks in DM draw code, perhaps better would be simply to flush changes from PBVH to DM. Anyway, now things seems to be working OK, will check on better solution from code point of view later.
2013-01-22 16:06:09 +00:00
/* TODO: same as for solid draw, not entirely correct, but works fine for now,
* will skip using textures (dyntopo currently destroys UV anyway) and
* works fine for matcap
*/
Fix issue reported by scorpion81 on irc: material mode + flat shading artifacts in cycles textured mode.
2015-07-17 18:30:40 +02:00
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
if (cddm->pbvh) {
if (cddm->pbvh_draw &&
BKE_pbvh_type(cddm->pbvh) == PBVH_BMESH &&
BKE_pbvh_has_faces(cddm->pbvh))
{
Fix part of #34239: crash with cycles textured draw mode + dynamic topology sculpt.
2013-02-15 16:56:42 +00:00
setMaterial(userData, 1, &gattribs);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
BKE_pbvh_draw(cddm->pbvh, NULL, NULL, NULL, false, false);
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
return;
}
else {
cdDM_update_normals_from_pbvh(dm);
Fix/workaround for GLSL textured and matcap modes for dyntopo Currently used special checks in DM draw code, perhaps better would be simply to flush changes from PBVH to DM. Anyway, now things seems to be working OK, will check on better solution from code point of view later.
2013-01-22 16:06:09 +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
matnr = -1;
glShadeModel(GL_SMOOTH);
memset(&attribs, 0, sizeof(attribs));
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
glBegin(GL_TRIANGLES);
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
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (a = 0; a < tottri; a++, lt++) {
const MPoly *mp = &mpoly[lt->poly];
const unsigned int vtri[3] = {mloop[lt->tri[0]].v, mloop[lt->tri[1]].v, mloop[lt->tri[2]].v};
const unsigned int *ltri = lt->tri;
const bool smoothnormal = lnors || (mp->flag & ME_SMOOTH);
const float *ln1 = NULL, *ln2 = NULL, *ln3 = NULL;
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
/* material */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
new_matnr = mp->mat_nr + 1;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (new_matnr != matnr) {
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
glEnd();
setMaterial(userData, matnr = new_matnr, &gattribs);
DM_vertex_attributes_from_gpu(dm, &gattribs, &attribs);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
glBegin(GL_TRIANGLES);
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
}
/* skipping faces */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (setFace) {
Fix issue reported by scorpion81 on irc: material mode + flat shading artifacts in cycles textured mode.
2015-07-17 18:30:40 +02:00
orig = (index_mp_to_orig) ? index_mp_to_orig[lt->poly] : lt->poly;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (orig != ORIGINDEX_NONE && !setFace(userData, orig))
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
continue;
}
/* smooth normal */
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!smoothnormal) {
if (nors) {
Fix issue reported by scorpion81 on irc: material mode + flat shading artifacts in cycles textured mode.
2015-07-17 18:30:40 +02:00
glNormal3fv(nors[lt->poly]);
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
}
else {
/* TODO ideally a normal layer should always be available */
float nor[3];
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
normal_tri_v3(nor, mvert[vtri[0]].co, mvert[vtri[1]].co, mvert[vtri[2]].co);
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
glNormal3fv(nor);
}
}
Fix T41862: Autosmooth & multi-material glitch
2014-09-18 14:55:33 +10:00
else if (lnors) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
ln1 = lnors[ltri[0]];
ln2 = lnors[ltri[1]];
ln3 = lnors[ltri[2]];
Split Normals I (3/5): Add 3Dview shading support of split normals. Mostly monkey coding in gpu ("modern" VBO drawing) and DM variants ("legacy" drawing) code... Reviewers: brecht Reviewed By: brecht CC: campbellbarton Differential Revision: https://developer.blender.org/D367
2014-04-13 12:29:21 +02: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
/* vertices */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
cddm_draw_attrib_vertex(&attribs, mvert, a, vtri[0], ltri[0], 0, ln1, smoothnormal);
cddm_draw_attrib_vertex(&attribs, mvert, a, vtri[1], ltri[1], 1, ln2, smoothnormal);
cddm_draw_attrib_vertex(&attribs, mvert, a, vtri[2], ltri[2], 2, ln3, smoothnormal);
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
}
glEnd();
glShadeModel(GL_FLAT);
}
Code cleanup: use typedefs for DerivedMesh drawing callbacks. There are still fairly bewildering set of callbacks being tossed around, but it's at least a little less verbose now.
2012-03-07 04:41:14 +00:00
static void cdDM_drawMappedEdges(DerivedMesh *dm, DMSetDrawOptions setDrawOptions, 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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MVert *vert = cddm->mvert;
MEdge *edge = cddm->medge;
int i, orig, *index = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
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
glBegin(GL_LINES);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
for (i = 0; i < dm->numEdgeData; i++, edge++) {
if (index) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
orig = *index++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (setDrawOptions && orig == ORIGINDEX_NONE) continue;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
}
else
orig = i;
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!setDrawOptions || (setDrawOptions(userData, orig) != DM_DRAW_OPTION_SKIP)) {
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
glVertex3fv(vert[edge->v1].co);
glVertex3fv(vert[edge->v2].co);
}
}
glEnd();
}
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
typedef struct FaceCount {
unsigned int i_visible;
unsigned int i_hidden;
unsigned int i_tri_visible;
unsigned int i_tri_hidden;
} FaceCount;
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_triangles(
DerivedMesh *dm, unsigned int *varray,
const int *mat_orig_to_new)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
GPUBufferMaterial *gpumat, *gpumaterials = dm->drawObject->materials;
int i, j, start;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
const int gpu_totmat = dm->drawObject->totmaterial;
const short dm_totmat = dm->totmat;
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
const MPoly *mpoly = dm->getPolyArray(dm);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MLoopTri *lt = dm->getLoopTriArray(dm);
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
const int totpoly = dm->getNumPolys(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
FaceCount *fc = MEM_mallocN(sizeof(*fc) * gpu_totmat, "gpumaterial.facecount");
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
for (i = 0; i < gpu_totmat; i++) {
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
fc[i].i_visible = 0;
fc[i].i_tri_visible = 0;
fc[i].i_hidden = gpumaterials[i].totpolys - 1;
fc[i].i_tri_hidden = gpumaterials[i].totelements - 1;
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
for (i = 0; i < totpoly; i++) {
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
const short mat_nr = ME_MAT_NR_TEST(mpoly[i].mat_nr, dm_totmat);
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
int tottri = ME_POLY_TRI_TOT(&mpoly[i]);
Fix T46073: crash w/ out-of-bounds material
2015-09-16 07:39:23 +10:00
int mati = mat_orig_to_new[mat_nr];
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
gpumat = gpumaterials + mati;
if (mpoly[i].flag & ME_HIDE) {
for (j = 0; j < tottri; j++, lt++) {
start = gpumat->start + fc[mati].i_tri_hidden;
/* v1 v2 v3 */
varray[start--] = lt->tri[2];
varray[start--] = lt->tri[1];
varray[start--] = lt->tri[0];
fc[mati].i_tri_hidden -= 3;
}
gpumat->polys[fc[mati].i_hidden--] = i;
}
else {
for (j = 0; j < tottri; j++, lt++) {
start = gpumat->start + fc[mati].i_tri_visible;
/* v1 v2 v3 */
varray[start++] = lt->tri[0];
varray[start++] = lt->tri[1];
varray[start++] = lt->tri[2];
fc[mati].i_tri_visible += 3;
}
gpumat->polys[fc[mati].i_visible++] = i;
}
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
/* set the visible polygons */
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
for (i = 0; i < gpu_totmat; i++) {
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
gpumaterials[i].totvisiblepolys = fc[i].i_visible;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
MEM_freeN(fc);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_vertex(
DerivedMesh *dm, float *varray)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MVert *mvert;
const MPoly *mpoly;
const MLoop *mloop;
int i, j, start, totpoly;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
mvert = dm->getVertArray(dm);
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
mpoly = dm->getPolyArray(dm);
mloop = dm->getLoopArray(dm);
totpoly = dm->getNumPolys(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpoly; i++, mpoly++) {
for (j = 0; j < mpoly->totloop; j++) {
copy_v3_v3(&varray[start], mvert[mloop[mpoly->loopstart + j].v].co);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start += 3;
}
}
/* copy loose points */
Fix yet another issue caused by my recent changes.
2015-07-24 14:32:11 +02:00
j = dm->drawObject->tot_loop_verts * 3;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (i = 0; i < dm->drawObject->totvert; i++) {
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
if (dm->drawObject->vert_points[i].point_index >= dm->drawObject->tot_loop_verts) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
copy_v3_v3(&varray[j], mvert[i].co);
j += 3;
}
}
}
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_normal(
DerivedMesh *dm, short *varray)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int i, j, totpoly;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int start;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const float (*nors)[3] = dm->getPolyDataArray(dm, CD_NORMAL);
const float (*lnors)[3] = dm->getLoopDataArray(dm, CD_NORMAL);
const MVert *mvert;
const MPoly *mpoly;
const MLoop *mloop;
mvert = dm->getVertArray(dm);
mpoly = dm->getPolyArray(dm);
mloop = dm->getLoopArray(dm);
totpoly = dm->getNumPolys(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Fix T46726 shading issues in sculpt mode. This fixes two issues: * Normals were not being recalculated correctly when not using optimized drawing for CDDerivedMesh (Multires actually handles that correctly). * Loop normals (autosmooth option) were also not being calculated. Doing this calculation is not desirable, since it can't be done correctly without a severe performance hit. This is easy to test by doing a dependency flush on the mesh after each scuplt stroke step. Instead they are now disabled during sculpting.
2015-11-13 21:57:00 +01:00
/* we are in sculpt mode, disable loop normals (since they won't get updated) */
if (cddm->pbvh)
lnors = NULL;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpoly; i++, mpoly++) {
const bool smoothnormal = (mpoly->flag & ME_SMOOTH) != 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (lnors) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
/* Copy loop normals */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (j = 0; j < mpoly->totloop; j++, start += 4) {
normal_float_to_short_v3(&varray[start], lnors[mpoly->loopstart + j]);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
}
else if (smoothnormal) {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
/* Copy vertex normal */
for (j = 0; j < mpoly->totloop; j++, start += 4) {
copy_v3_v3_short(&varray[start], mvert[mloop[mpoly->loopstart + j].v].no);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
}
else {
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
/* Copy cached OR calculated face normal */
Fix autosmooth with recent DM optimizations Also avoid multiple float->short conversions for the same normal.
2015-07-15 14:32:11 +10:00
short f_no_s[3];
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if (nors) {
normal_float_to_short_v3(f_no_s, nors[i]);
}
else {
float f_no[3];
BKE_mesh_calc_poly_normal(mpoly, &mloop[mpoly->loopstart], mvert, f_no);
normal_float_to_short_v3(f_no_s, f_no);
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (j = 0; j < mpoly->totloop; j++, start += 4) {
Fix autosmooth with recent DM optimizations Also avoid multiple float->short conversions for the same normal.
2015-07-15 14:32:11 +10:00
copy_v3_v3_short(&varray[start], f_no_s);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
}
}
}
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_uv(
DerivedMesh *dm, float *varray)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int i, j, totpoly;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int start;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly;
const MLoopUV *mloopuv;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if ((mloopuv = DM_get_loop_data_layer(dm, CD_MLOOPUV)) == NULL) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
return;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
}
mpoly = dm->getPolyArray(dm);
totpoly = dm->getNumPolys(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpoly; i++, mpoly++) {
for (j = 0; j < mpoly->totloop; j++) {
copy_v2_v2(&varray[start], mloopuv[mpoly->loopstart + j].uv);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start += 2;
}
}
}
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_uv_texpaint(
DerivedMesh *dm, float *varray)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int i, j, totpoly;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int start;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int totmaterial = dm->totmat;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MLoopUV **uv_base;
const MLoopUV *uv_stencil_base;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int stencil;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
totpoly = dm->getNumPolys(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
/* should have been checked for before, reassert */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
BLI_assert(DM_get_loop_data_layer(dm, CD_MLOOPUV));
uv_base = MEM_mallocN(totmaterial * sizeof(*uv_base), "texslots");
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
for (i = 0; i < totmaterial; i++) {
Remove MTFace DM_paint_uvlayer_active_get func
2015-07-17 04:26:17 +10:00
uv_base[i] = DM_paint_uvlayer_active_get(dm, i);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
stencil = CustomData_get_stencil_layer(&dm->loopData, CD_MLOOPUV);
uv_stencil_base = CustomData_get_layer_n(&dm->loopData, CD_MLOOPUV, stencil);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
mpoly = dm->getPolyArray(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpoly; i++, mpoly++) {
int mat_i = mpoly->mat_nr;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (j = 0; j < mpoly->totloop; j++) {
copy_v2_v2(&varray[start], uv_base[mat_i][mpoly->loopstart + j].uv);
copy_v2_v2(&varray[start + 2], uv_stencil_base[mpoly->loopstart + j].uv);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start += 4;
}
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
MEM_freeN(uv_base);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
/* treat varray_ as an array of MCol, four MCol's per face */
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_mcol(
DerivedMesh *dm, unsigned char *varray,
const void *user_data)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int i, j, totpoly;
int start;
const MLoopCol *mloopcol = user_data;
const MPoly *mpoly = dm->getPolyArray(dm);
totpoly = dm->getNumPolys(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start = 0;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpoly; i++, mpoly++) {
for (j = 0; j < mpoly->totloop; j++) {
Fix warnings and remove casts by adding copy_vx_vx_uchar() functions.
2015-10-11 01:44:47 +02:00
copy_v3_v3_uchar(&varray[start], &mloopcol[mpoly->loopstart + j].r);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
start += 3;
}
}
}
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_edge(
DerivedMesh *dm, unsigned int *varray)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
MEdge *medge, *medge_base;
int i, totedge, iloose, inorm, iloosehidden, inormhidden;
int tot_loose_hidden = 0, tot_loose = 0;
int tot_hidden = 0, tot = 0;
medge_base = medge = dm->getEdgeArray(dm);
totedge = dm->getNumEdges(dm);
for (i = 0; i < totedge; i++, medge++) {
if (medge->flag & ME_EDGEDRAW) {
if (medge->flag & ME_LOOSEEDGE) tot_loose++;
else tot++;
}
else {
if (medge->flag & ME_LOOSEEDGE) tot_loose_hidden++;
else tot_hidden++;
}
}
inorm = 0;
inormhidden = tot;
iloose = tot + tot_hidden;
iloosehidden = iloose + tot_loose;
medge = medge_base;
for (i = 0; i < totedge; i++, medge++) {
if (medge->flag & ME_EDGEDRAW) {
if (medge->flag & ME_LOOSEEDGE) {
varray[iloose * 2] = dm->drawObject->vert_points[medge->v1].point_index;
varray[iloose * 2 + 1] = dm->drawObject->vert_points[medge->v2].point_index;
iloose++;
}
else {
varray[inorm * 2] = dm->drawObject->vert_points[medge->v1].point_index;
varray[inorm * 2 + 1] = dm->drawObject->vert_points[medge->v2].point_index;
inorm++;
}
}
else {
if (medge->flag & ME_LOOSEEDGE) {
varray[iloosehidden * 2] = dm->drawObject->vert_points[medge->v1].point_index;
varray[iloosehidden * 2 + 1] = dm->drawObject->vert_points[medge->v2].point_index;
iloosehidden++;
}
else {
varray[inormhidden * 2] = dm->drawObject->vert_points[medge->v1].point_index;
varray[inormhidden * 2 + 1] = dm->drawObject->vert_points[medge->v2].point_index;
inormhidden++;
}
}
}
dm->drawObject->tot_loose_edge_drawn = tot_loose;
dm->drawObject->loose_edge_offset = tot + tot_hidden;
dm->drawObject->tot_edge_drawn = tot;
}
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
static void cdDM_buffer_copy_uvedge(
DerivedMesh *dm, float *varray)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
int i, j, totpoly;
int start;
const MLoopUV *mloopuv;
const MPoly *mpoly = dm->getPolyArray(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
if ((mloopuv = DM_get_loop_data_layer(dm, CD_MLOOPUV)) == NULL) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
return;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
}
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
totpoly = dm->getNumPolys(dm);
start = 0;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpoly; i++, mpoly++) {
for (j = 0; j < mpoly->totloop; j++) {
copy_v2_v2(&varray[start], mloopuv[mpoly->loopstart + j].uv);
copy_v2_v2(&varray[start + 2], mloopuv[mpoly->loopstart + (j + 1) % mpoly->totloop].uv);
start += 4;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
}
}
Cleanup: ws
2015-07-15 11:43:23 +10:00
static void cdDM_copy_gpu_data(
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
DerivedMesh *dm, int type, void *varray_p,
const int *mat_orig_to_new, const void *user_data)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
/* 'varray_p' cast is redundant but include for self-documentation */
Cleanup: ws
2015-07-15 11:43:23 +10:00
switch (type) {
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
case GPU_BUFFER_VERTEX:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_vertex(dm, (float *)varray_p);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_NORMAL:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_normal(dm, (short *)varray_p);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_COLOR:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_mcol(dm, (unsigned char *)varray_p, user_data);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_UV:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_uv(dm, (float *)varray_p);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_UV_TEXPAINT:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_uv_texpaint(dm, (float *)varray_p);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_EDGE:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_edge(dm, (unsigned int *)varray_p);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_UVEDGE:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_uvedge(dm, (float *)varray_p);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
case GPU_BUFFER_TRIANGLES:
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
cdDM_buffer_copy_triangles(dm, (unsigned int *)varray_p, mat_orig_to_new);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
break;
default:
break;
}
}
/* add a new point to the list of points related to a particular
* vertex */
#ifdef USE_GPU_POINT_LINK
static void cdDM_drawobject_add_vert_point(GPUDrawObject *gdo, int vert_index, int point_index)
{
GPUVertPointLink *lnk;
lnk = &gdo->vert_points[vert_index];
/* if first link is in use, add a new link at the end */
if (lnk->point_index != -1) {
/* get last link */
for (; lnk->next; lnk = lnk->next) ;
/* add a new link from the pool */
lnk = lnk->next = &gdo->vert_points_mem[gdo->vert_points_usage];
gdo->vert_points_usage++;
}
lnk->point_index = point_index;
}
#else
static void cdDM_drawobject_add_vert_point(GPUDrawObject *gdo, int vert_index, int point_index)
{
GPUVertPointLink *lnk;
lnk = &gdo->vert_points[vert_index];
if (lnk->point_index == -1) {
lnk->point_index = point_index;
}
}
#endif /* USE_GPU_POINT_LINK */
/* for each vertex, build a list of points related to it; these lists
* are stored in an array sized to the number of vertices */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
static void cdDM_drawobject_init_vert_points(
GPUDrawObject *gdo,
const MPoly *mpoly, const MLoop *mloop,
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
int tot_poly)
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
{
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
int i;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
int tot_loops = 0;
/* allocate the array and space for links */
gdo->vert_points = MEM_mallocN(sizeof(GPUVertPointLink) * gdo->totvert,
"GPUDrawObject.vert_points");
#ifdef USE_GPU_POINT_LINK
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
gdo->vert_points_mem = MEM_callocN(sizeof(GPUVertPointLink) * gdo->totvert,
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
"GPUDrawObject.vert_points_mem");
gdo->vert_points_usage = 0;
#endif
/* -1 indicates the link is not yet used */
for (i = 0; i < gdo->totvert; i++) {
#ifdef USE_GPU_POINT_LINK
gdo->vert_points[i].link = NULL;
#endif
gdo->vert_points[i].point_index = -1;
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < tot_poly; i++) {
int j;
const MPoly *mp = &mpoly[i];
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
/* assign unique indices to vertices of the mesh */
for (j = 0; j < mp->totloop; j++) {
cdDM_drawobject_add_vert_point(gdo, mloop[mp->loopstart + j].v, tot_loops + j);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
tot_loops += mp->totloop;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
/* map any unused vertices to loose points */
for (i = 0; i < gdo->totvert; i++) {
if (gdo->vert_points[i].point_index == -1) {
Fix out of bounds memory access when copying loose vertices in cddm Caused by own fix for too much allocated memory not taking all code into account.
2015-07-24 12:24:05 +02:00
gdo->vert_points[i].point_index = gdo->tot_loop_verts + gdo->tot_loose_point;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
gdo->tot_loose_point++;
}
}
}
/* see GPUDrawObject's structure definition for a description of the
* data being initialized here */
static GPUDrawObject *cdDM_GPUobject_new(DerivedMesh *dm)
{
GPUDrawObject *gdo;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
const MPoly *mpoly;
const MLoop *mloop;
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
const short dm_totmat = dm->totmat;
GPU buffer materials: Separate and reuse some shared code. Also avoid counting for information we already know, such as total loop triangles etc.
2015-07-25 13:17:37 +02:00
GPUBufferMaterial *mat_info;
int i, totloops, totpolys;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
/* object contains at least one material (default included) so zero means uninitialized dm */
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
BLI_assert(dm_totmat != 0);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
mpoly = dm->getPolyArray(dm);
mloop = dm->getLoopArray(dm);
totpolys = dm->getNumPolys(dm);
GPU buffer materials: Separate and reuse some shared code. Also avoid counting for information we already know, such as total loop triangles etc.
2015-07-25 13:17:37 +02:00
totloops = dm->getNumLoops(dm);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
/* get the number of points used by each material, treating
* each quad as two triangles */
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
mat_info = MEM_callocN(sizeof(*mat_info) * dm_totmat, "GPU_drawobject_new.mat_orig_to_new");
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
for (i = 0; i < totpolys; i++) {
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
const short mat_nr = ME_MAT_NR_TEST(mpoly[i].mat_nr, dm_totmat);
GPU buffer materials: Separate and reuse some shared code. Also avoid counting for information we already know, such as total loop triangles etc.
2015-07-25 13:17:37 +02:00
mat_info[mat_nr].totpolys++;
mat_info[mat_nr].totelements += 3 * ME_POLY_TRI_TOT(&mpoly[i]);
mat_info[mat_nr].totloops += mpoly[i].totloop;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
}
/* create the GPUDrawObject */
gdo = MEM_callocN(sizeof(GPUDrawObject), "GPUDrawObject");
gdo->totvert = dm->getNumVerts(dm);
gdo->totedge = dm->getNumEdges(dm);
Fix for recent regression clamping materials Mixup between gpu/derivedMesh total materials, fix and name more clearly to avoid confusion. thanks to Sergey for finding root cause!
2015-09-17 20:40:51 +10:00
GPU_buffer_material_finalize(gdo, mat_info, dm_totmat);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
gdo->tot_loop_verts = totloops;
/* store total number of points used for triangles */
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
gdo->tot_triangle_point = poly_to_tri_count(totpolys, totloops) * 3;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
GPU Buffers: This commit begins implementation of the idea about hidden face separation outlined in http://code.blender.org/2015/06/optimizing-blenders-real-time-mesh- We split hidden and visible faces to different parts of the triangle buffer. Mapped drawing will now skip iterating through hidden polys. Of course the final target, when all derived mesh types use VBO sorting, is to skip checking for hide flag per face completely. All faces will be pre-sorted anyway and we'll be able to draw them with one draw call.
2015-07-25 20:00:49 +02:00
cdDM_drawobject_init_vert_points(gdo, mpoly, mloop, totpolys);
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
return gdo;
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
static void cdDM_foreachMappedVert(
use 'const float[3]' for derived mesh callback args.
2012-04-09 07:06:06 +00:00
DerivedMesh *dm,
void (*func)(void *userData, int index, const float co[3], const float no_f[3], const short no_s[3]),
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
void *userData,
DMForeachFlag flag)
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
MVert *mv = CDDM_get_verts(dm);
Code cleanup: use 'const' for arrays (blenkernel)
2014-04-27 00:20:13 +10:00
const int *index = DM_get_vert_data_layer(dm, CD_ORIGINDEX);
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
int i;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
if (index) {
for (i = 0; i < dm->numVertData; i++, mv++) {
const short *no = (flag & DM_FOREACH_USE_NORMAL) ? mv->no : NULL;
const int orig = *index++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (orig == ORIGINDEX_NONE) continue;
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
func(userData, orig, mv->co, NULL, no);
}
}
else {
for (i = 0; i < dm->numVertData; i++, mv++) {
const short *no = (flag & DM_FOREACH_USE_NORMAL) ? mv->no : NULL;
func(userData, i, mv->co, NULL, no);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
}
}
}
static void cdDM_foreachMappedEdge(
use 'const float[3]' for derived mesh callback args.
2012-04-09 07:06:06 +00:00
DerivedMesh *dm,
void (*func)(void *userData, int index, const float v0co[3], const float v1co[3]),
void *userData)
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *) dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MVert *mv = cddm->mvert;
MEdge *med = cddm->medge;
int i, orig, *index = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
for (i = 0; i < dm->numEdgeData; i++, med++) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
if (index) {
orig = *index++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (orig == ORIGINDEX_NONE) continue;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
func(userData, orig, mv[med->v1].co, mv[med->v2].co);
}
else
func(userData, i, mv[med->v1].co, mv[med->v2].co);
}
}
Fix T39781: Autosmooth feature: erroneously showing hidden vertices' normals too when in "vertex per face" display So, turned out after all we need a foreachmapped helper for loops as well... :/ CDDM and EBDM were reasonably simple, but I fought hours with CCGDM (subsurf) to find only a bad working solution (see D478). So I fallback to a code similar to CDDM one. Probably not nice for performances, but loops and subsurf are not matching well... Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D478
2014-04-23 15:18:11 +02:00
static void cdDM_foreachMappedLoop(
DerivedMesh *dm,
void (*func)(void *userData, int vertex_index, int face_index, const float co[3], const float no[3]),
void *userData,
DMForeachFlag flag)
{
/* We can't use dm->getLoopDataLayout(dm) here, we want to always access dm->loopData, EditDerivedBMesh would
* return loop data from bmesh itself. */
const float (*lnors)[3] = (flag & DM_FOREACH_USE_NORMAL) ? DM_get_loop_data_layer(dm, CD_NORMAL) : NULL;
const MVert *mv = CDDM_get_verts(dm);
const MLoop *ml = CDDM_get_loops(dm);
const MPoly *mp = CDDM_get_polys(dm);
const int *v_index = DM_get_vert_data_layer(dm, CD_ORIGINDEX);
const int *f_index = DM_get_poly_data_layer(dm, CD_ORIGINDEX);
int p_idx, i;
for (p_idx = 0; p_idx < dm->numPolyData; ++p_idx, ++mp) {
for (i = 0; i < mp->totloop; ++i, ++ml) {
const int v_idx = v_index ? v_index[ml->v] : ml->v;
const int f_idx = f_index ? f_index[p_idx] : p_idx;
const float *no = lnors ? *lnors++ : NULL;
if (!ELEM(ORIGINDEX_NONE, v_idx, f_idx)) {
func(userData, v_idx, f_idx, mv[ml->v].co, no);
}
}
}
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
static void cdDM_foreachMappedFaceCenter(
use 'const float[3]' for derived mesh callback args.
2012-04-09 07:06:06 +00:00
DerivedMesh *dm,
void (*func)(void *userData, int index, const float cent[3], const float no[3]),
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
void *userData,
DMForeachFlag flag)
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
code cleanup: fix possible use of uninitialized value and remove dead initializations.
2012-05-23 21:39:39 +00:00
MVert *mvert = cddm->mvert;
MPoly *mp;
MLoop *ml;
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
int i, orig, *index;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
further fixes for modifiers, and edge loop select works now.
2009-06-16 20:08:40 +00:00
index = CustomData_get_layer(&dm->polyData, CD_ORIGINDEX);
rename MPoly vars called mface or mf, to avoid confusion with MFace types.
2012-04-03 23:40:24 +00:00
mp = cddm->mpoly;
for (i = 0; i < dm->numPolyData; i++, mp++) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
float cent[3];
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
float *no, _no[3];
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
if (index) {
orig = *index++;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (orig == ORIGINDEX_NONE) continue;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
}
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
else {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
orig = i;
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +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
rename MPoly vars called mface or mf, to avoid confusion with MFace types.
2012-04-03 23:40:24 +00:00
ml = &cddm->mloop[mp->loopstart];
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
BKE_mesh_calc_poly_center(mp, ml, mvert, cent);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
if (flag & DM_FOREACH_USE_NORMAL) {
BKE_mesh_calc_poly_normal(mp, ml, mvert, (no = _no));
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
}
else {
optimization: only calculate the normals for passing into derivedMesh foreachMappedVert/foreachMappedFaceCenter when needed, this means in editmode with wire draw, face and vertex normals don't have to be calculated at all. in most cases the normals are not used so add a flag that makes calculating them only for functions that need them. also fix face normal calculation for CDDM, was using quad calculation for ngons too.
2013-07-22 22:59:47 +00:00
no = NULL;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
}
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
func(userData, orig, cent, no);
}
further fixes for modifiers, and edge loop select works now.
2009-06-16 20:08:40 +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
}
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
void CDDM_recalc_tessellation_ex(DerivedMesh *dm, const bool do_face_nor_cpy)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
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
Cleanup: ws
2015-07-15 12:08:32 +10:00
dm->numTessFaceData = BKE_mesh_recalc_tessellation(
&dm->faceData, &dm->loopData, &dm->polyData,
cddm->mvert,
dm->numTessFaceData, dm->numLoopData, dm->numPolyData,
do_face_nor_cpy);
r42101 causes problems. reverting and instead make correct CD_ORIGINDEX for tesselated faces to fix the problem.
2011-11-23 20:44:04 +00:00
a bug fix and a compile fix
2009-11-03 05:06:04 +00:00
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
Fix for [#29467] Selection of active vertex color layer doesn't work Need to push active layer indices from loops & polys to faces again after tesselations
2011-12-01 09:49:27 +00:00
style cleanup - spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-02 16:05:54 +00:00
/* Tessellation recreated faceData, and the active layer indices need to get re-propagated
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
* from loops and polys to faces */
Fix for [#29467] Selection of active vertex color layer doesn't work Need to push active layer indices from loops & polys to faces again after tesselations
2011-12-01 09:49:27 +00:00
CustomData_bmesh_update_active_layers(&dm->faceData, &dm->polyData, &dm->loopData);
a bug fix and a compile fix
2009-11-03 05:06:04 +00:00
}
style cleanup - spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-02 16:05:54 +00:00
void CDDM_recalc_tessellation(DerivedMesh *dm)
ensure defoem DM has tessface data for the few places that need it. also add a workaround for CDDM_recalc_tesselation_ex() which would add a CD_NORMAL to dm->fdata and then overwrite immediate
2012-01-19 19:23:25 +00:00
{
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
CDDM_recalc_tessellation_ex(dm, true);
ensure defoem DM has tessface data for the few places that need it. also add a workaround for CDDM_recalc_tesselation_ex() which would add a CD_NORMAL to dm->fdata and then overwrite immediate
2012-01-19 19:23:25 +00:00
}
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
void CDDM_recalc_looptri(DerivedMesh *dm)
{
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
const unsigned int totpoly = dm->numPolyData;
const unsigned int totloop = dm->numLoopData;
DM_ensure_looptri_data(dm);
BKE_mesh_recalc_looptri(
cddm->mloop, cddm->mpoly,
cddm->mvert,
totloop, totpoly,
cddm->dm.looptris.array);
}
static const MLoopTri *cdDM_getLoopTriArray(DerivedMesh *dm)
{
if (dm->looptris.array) {
BLI_assert(poly_to_tri_count(dm->numPolyData, dm->numLoopData) == dm->looptris.num);
}
else {
dm->recalcLoopTri(dm);
/* ccdm is an exception here, that recalcLoopTri will fill in the array too */
}
return dm->looptris.array;
}
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
static void cdDM_free_internal(CDDerivedMesh *cddm)
{
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (cddm->pmap) MEM_freeN(cddm->pmap);
if (cddm->pmap_mem) MEM_freeN(cddm->pmap_mem);
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
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
static void cdDM_release(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
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
if (DM_release(dm)) {
cdDM_free_internal(cddm);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MEM_freeN(cddm);
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
}
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
/**************** CDDM interface functions ****************/
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
static CDDerivedMesh *cdDM_create(const char *desc)
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
CDDerivedMesh *cddm;
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
DerivedMesh *dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
cddm = MEM_callocN(sizeof(*cddm), desc);
dm = &cddm->dm;
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
dm->getMinMax = cdDM_getMinMax;
dm->getNumVerts = cdDM_getNumVerts;
dm->getNumEdges = cdDM_getNumEdges;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
dm->getNumTessFaces = cdDM_getNumTessFaces;
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
dm->getNumLoops = cdDM_getNumLoops;
More DM func renames, this one includes renames of the function pointer members of the DerivedMesh struct
2011-11-29 13:01:51 +00:00
dm->getNumPolys = cdDM_getNumPolys;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
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
dm->getVert = cdDM_getVert;
dm->getEdge = cdDM_getEdge;
More DM func renames, this one includes renames of the function pointer members of the DerivedMesh struct
2011-11-29 13:01:51 +00:00
dm->getTessFace = cdDM_getTessFace;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
dm->copyVertArray = cdDM_copyVertArray;
dm->copyEdgeArray = cdDM_copyEdgeArray;
More DM func renames, this one includes renames of the function pointer members of the DerivedMesh struct
2011-11-29 13:01:51 +00:00
dm->copyTessFaceArray = cdDM_copyTessFaceArray;
=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
dm->copyLoopArray = cdDM_copyLoopArray;
dm->copyPolyArray = cdDM_copyPolyArray;
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
More DM func renames, this one includes renames of the function pointer members of the DerivedMesh struct
2011-11-29 13:01:51 +00:00
dm->getVertData = DM_get_vert_data;
dm->getEdgeData = DM_get_edge_data;
dm->getTessFaceData = DM_get_tessface_data;
dm->getVertDataArray = DM_get_vert_data_layer;
dm->getEdgeDataArray = DM_get_edge_data_layer;
dm->getTessFaceDataArray = DM_get_tessface_data_layer;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
dm->getLoopTriArray = cdDM_getLoopTriArray;
remove CD_MASK_NORMAL from CD_MASK_DERIVEDMESH, bmesh merge included this but its not needed. Now add asserts to make sure this layer is only added once the modifier stack has been calculated. this saves normal layer being calculated whenver vertex normals need updating.
2013-05-30 18:09:19 +00:00
dm->calcNormals = CDDM_calc_normals;
Split Normals I (1/5): basis for split normals (nearly nothing user-visible here): * Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf). EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit. * Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it (tessellation, rna access, etc.). * Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding this option is now incoherent, will be addressed in a separate commit. Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D365
2014-04-13 12:18:51 +02:00
dm->calcLoopNormals = CDDM_calc_loop_normals;
Add Custom Loop Normals. This is the core code for it, tools (datatransfer and modifier) will come in next commits). RNA api is already there, though. See the code for details, but basically, we define, for each 'smooth fan' (which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal), a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store custom normal as two angular factors inside that space. This allows to have custom normals 'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer. Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals, and be converted back into storage format at the end. Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can be rather heavy with high poly meshes. Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
dm->calcLoopNormalsSpaceArray = CDDM_calc_loop_normals_spacearr;
Fix editmesh GLSL tangent drawing The generic tangent calculation relied on CDDM arrays which aren't available in edit-mode. Add a tangent calculation callback, which has its own implementation for editmesh data.
2015-08-24 15:14:34 +10:00
dm->calcLoopTangents = DM_calc_loop_tangents;
style cleanup - spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-02 16:05:54 +00:00
dm->recalcTessellation = CDDM_recalc_tessellation;
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
dm->recalcLoopTri = CDDM_recalc_looptri;
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
dm->getVertCos = cdDM_getVertCos;
dm->getVertCo = cdDM_getVertCo;
dm->getVertNo = cdDM_getVertNo;
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
dm->getPBVH = cdDM_getPBVH;
add function for getting a polygon map: dm->getPolyMap(ob, dm). polygon version of dm->getFaceMap(ob, dm) sculpt uses this for checking connectivity.
2012-02-05 06:20:51 +00:00
dm->getPolyMap = cdDM_getPolyMap;
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
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
dm->drawVerts = cdDM_drawVerts;
dm->drawUVEdges = cdDM_drawUVEdges;
dm->drawEdges = cdDM_drawEdges;
dm->drawLooseEdges = cdDM_drawLooseEdges;
dm->drawMappedEdges = cdDM_drawMappedEdges;
dm->drawFacesSolid = cdDM_drawFacesSolid;
dm->drawFacesTex = cdDM_drawFacesTex;
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
dm->drawFacesGLSL = cdDM_drawFacesGLSL;
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
dm->drawMappedFaces = cdDM_drawMappedFaces;
dm->drawMappedFacesTex = cdDM_drawMappedFacesTex;
Merge of first part of changes from the apricot branch, especially the features that are needed to run the game. Compile tested with scons, make, but not cmake, that seems to have an issue not related to these changes. The changes include: * GLSL support in the viewport and game engine, enable in the game menu in textured draw mode. * Synced and merged part of the duplicated blender and gameengine/ gameplayer drawing code. * Further refactoring of game engine drawing code, especially mesh storage changed a lot. * Optimizations in game engine armatures to avoid recomputations. * A python function to get the framerate estimate in game. * An option take object color into account in materials. * An option to restrict shadow casters to a lamp's layers. * Increase from 10 to 18 texture slots for materials, lamps, word. An extra texture slot shows up once the last slot is used. * Memory limit for undo, not enabled by default yet because it needs the .B.blend to be changed. * Multiple undo for image painting. * An offset for dupligroups, so not all objects in a group have to be at the origin.
2008-09-04 20:51:28 +00:00
dm->drawMappedFacesGLSL = cdDM_drawMappedFacesGLSL;
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
dm->drawMappedFacesMat = cdDM_drawMappedFacesMat;
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
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02:00
dm->gpuObjectNew = cdDM_GPUobject_new;
DerivedMesh: minor changes to callback use - use void instead of float for array arg (cast in the switch statement) - remove unused args - use const for poly-mapping and user_data args
2015-07-15 12:42:41 +10:00
dm->copy_gpu_data = cdDM_copy_gpu_data;
Display optimizations part 1. This patch changes the way we draw meshes by introducing indexed drawing. This makes it possible to easily upload and rearrange faces ad lib according to any criteria. Currently we use material sorting but textured sorting and hiding will be added to optimize textured drawing and skip per face testing. It also adds support for vertex buffers for subsurf modifiers (Except from GLSL drawing), making drawing of subsurf much faster without need for bogus modifiers. Tests show that we gain approximately 20-25% performance by that for solid mode drawing with up to 50% gains for material drawing. Textured drawing should also have a small performance gain, but more substantial optimizations are possible there. Reviewers: campbellbarton Differential Revision: https://developer.blender.org/D1406
2015-07-14 16:48:23 +02: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
dm->foreachMappedVert = cdDM_foreachMappedVert;
dm->foreachMappedEdge = cdDM_foreachMappedEdge;
Fix T39781: Autosmooth feature: erroneously showing hidden vertices' normals too when in "vertex per face" display So, turned out after all we need a foreachmapped helper for loops as well... :/ CDDM and EBDM were reasonably simple, but I fought hours with CCGDM (subsurf) to find only a bad working solution (see D478). So I fallback to a code similar to CDDM one. Probably not nice for performances, but loops and subsurf are not matching well... Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D478
2014-04-23 15:18:11 +02:00
dm->foreachMappedLoop = cdDM_foreachMappedLoop;
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
dm->foreachMappedFaceCenter = cdDM_foreachMappedFaceCenter;
dm->release = cdDM_release;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
return cddm;
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
}
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
DerivedMesh *CDDM_new(int numVerts, int numEdges, int numTessFaces, 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
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
CDDerivedMesh *cddm = cdDM_create("CDDM_new dm");
DerivedMesh *dm = &cddm->dm;
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
DM_init(dm, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces, numLoops, 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
Revision 15045 merged from apricot ---------------------------------- Small fix to derivedmesh for snapping: don't create origindex for editmesh derivedmesh since it's not being filled correct anyway.
2008-06-09 17:22:38 +00:00
CustomData_add_layer(&dm->vertData, CD_ORIGINDEX, CD_CALLOC, NULL, numVerts);
CustomData_add_layer(&dm->edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
CustomData_add_layer(&dm->polyData, CD_ORIGINDEX, CD_CALLOC, NULL, numPolys);
Revision 15045 merged from apricot ---------------------------------- Small fix to derivedmesh for snapping: don't create origindex for editmesh derivedmesh since it's not being filled correct anyway.
2008-06-09 17:22:38 +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
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_CALLOC, NULL, numVerts);
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_CALLOC, NULL, numTessFaces);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
CustomData_add_layer(&dm->loopData, CD_MLOOP, CD_CALLOC, NULL, numLoops);
CustomData_add_layer(&dm->polyData, CD_MPOLY, CD_CALLOC, NULL, numPolys);
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
cddm->mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
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 dm;
}
Code Cleanup: remove object arg to CDDM_from_mesh mesh_create_derived
2013-12-26 08:26:41 +11:00
DerivedMesh *CDDM_from_mesh(Mesh *mesh)
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
{
Code Cleanup: remove object arg to CDDM_from_mesh mesh_create_derived
2013-12-26 08:26:41 +11:00
CDDerivedMesh *cddm = cdDM_create(__func__);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
DerivedMesh *dm = &cddm->dm;
Got rid of old multires code, brought in multires modifier from soc-2008-nicholasbishop branch. Note: any old code with multires_test() or multires_level1_test() can just be deleted, not needed by the multires modifier.
2009-01-06 18:59:03 +00:00
CustomDataMask mask = CD_MASK_MESH & (~CD_MASK_MDISPS);
Sculpt: derivedmesh no longer created CD_ORIGINDEX layer when there is no modifier, saving some memory.
2009-11-04 20:23:48 +00:00
int alloctype;
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
Sculpt: derivedmesh no longer created CD_ORIGINDEX layer when there is no modifier, saving some memory.
2009-11-04 20:23:48 +00:00
/* this does a referenced copy, with an exception for fluidsim */
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
Don't initialize CDDM with MFace from Meshes Caused crash because MFace is no longer a layer which is added unless requested, causing CDDM to have numTessFaceData nonzero, but mface set to NULL.
2015-07-31 11:52:21 +10:00
DM_init(dm, DM_TYPE_CDDM, mesh->totvert, mesh->totedge, 0 /* mesh->totface */,
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
mesh->totloop, mesh->totpoly);
Revision 15045 merged from apricot ---------------------------------- Small fix to derivedmesh for snapping: don't create origindex for editmesh derivedmesh since it's not being filled correct anyway.
2008-06-09 17:22:38 +00:00
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 22:09:57 +00:00
dm->deformedOnly = 1;
don't store bevel weights or edge crease customdata layers in editmode unless they are needed. configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
2013-01-10 04:43:31 +00:00
dm->cd_flag = mesh->cd_flag;
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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
alloctype = CD_REFERENCE;
Fix for bug #8321: crash with fluidsim in shaded draw mode.
2008-02-21 13:15:21 +00:00
Got rid of old multires code, brought in multires modifier from soc-2008-nicholasbishop branch. Note: any old code with multires_test() or multires_level1_test() can just be deleted, not needed by the multires modifier.
2009-01-06 18:59:03 +00:00
CustomData_merge(&mesh->vdata, &dm->vertData, mask, alloctype,
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
mesh->totvert);
Got rid of old multires code, brought in multires modifier from soc-2008-nicholasbishop branch. Note: any old code with multires_test() or multires_level1_test() can just be deleted, not needed by the multires modifier.
2009-01-06 18:59:03 +00:00
CustomData_merge(&mesh->edata, &dm->edgeData, mask, alloctype,
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
mesh->totedge);
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
CustomData_merge(&mesh->fdata, &dm->faceData, mask | CD_MASK_ORIGINDEX, alloctype,
Don't initialize CDDM with MFace from Meshes Caused crash because MFace is no longer a layer which is added unless requested, causing CDDM to have numTessFaceData nonzero, but mface set to NULL.
2015-07-31 11:52:21 +10:00
0 /* mesh->totface */);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
CustomData_merge(&mesh->ldata, &dm->loopData, mask, alloctype,
mesh->totloop);
CustomData_merge(&mesh->pdata, &dm->polyData, mask, alloctype,
mesh->totpoly);
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
cddm->mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
Don't initialize CDDM with MFace from Meshes Caused crash because MFace is no longer a layer which is added unless requested, causing CDDM to have numTessFaceData nonzero, but mface set to NULL.
2015-07-31 11:52:21 +10:00
#if 0
part one of profiling/optimizing. made cddm not update tesselations itself in cddm_from_mesh. also made BMO_Test/Set/ClearFlag into macros, and tweaked the way normals are calculated.
2009-09-05 06:10:30 +00:00
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
Don't initialize CDDM with MFace from Meshes Caused crash because MFace is no longer a layer which is added unless requested, causing CDDM to have numTessFaceData nonzero, but mface set to NULL.
2015-07-31 11:52:21 +10:00
#else
cddm->mface = NULL;
#endif
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
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
/* commented since even when CD_ORIGINDEX was first added this line fails
remove assert & make warning print more helpful
2011-11-23 16:39:07 +00:00
* on the default cube, (after editmode toggle too) - campbell */
#if 0
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
BLI_assert(CustomData_has_layer(&cddm->dm.faceData, CD_ORIGINDEX));
remove assert & make warning print more helpful
2011-11-23 16:39:07 +00:00
#endif
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +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
return 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
DerivedMesh *CDDM_from_curve(Object *ob)
- Fixed trouble with rendering curves with disabled modifiers, which are disabled for realtime displaying but enabled for rendering. - Calculate tex space for curves before modifiers applying.
2010-03-08 13:49:13 +00:00
{
Made curves almost thread-safe Now modifier stack wouldn't modify original curve's nurbs and will operate on a copy of nurbs. This makes it possible to process curve object update with shared curve datablocks from multiple threads. There's no big overhead for creating a copy of nurbs comparing to old behavior which was allocating original vertex array and apply coordinates on curve after all modifier are applied. The only remained issue with curves is curve's bounding box and texture space. It's not thread-safe, but it wouldn't lead to crashes -- it just could lead to either memory leak or wrong texture coordinates due to difference in modifiers stacks of objects which shares the same curve. -- svn merge -r57959:57961 ^/branches/soc-2013-depsgraph_mt
2013-08-19 09:36:40 +00:00
ListBase disp = {NULL, NULL};
Move bevel list and path from Curve to Object datablock I know this is not so much nice to have this guys hanging around in a general Object datablock and ideally they better be wrapped around into a structure like DerivedMesh or something like this. But this is pure runtime only stuff and we could re-wrap them around later. Main purpose of this is making curves more thread safe, so no separate threads will ever start freeing the same path or the same bevel list. It also makes sense because path and bevel shall include deformation coming from modifiers which are applying on pre-tesselation point and different objects could have different set of modifiers. This used to be really confusing in the past and now data which depends on object is stored in an object, making things clear for understanding even. This doesn't make curve code fully thread-safe due to pre-tesselation modifiers still modifies actual nurbs and lock is still needed in makeDispListsCurveTypes, but this change makes usage of paths safe for threading. Once modifiers will stop modifying actual nurbs, curves will be fully safe for threading. Actually, this commit also contains wrapping runtime curve members into own structure This allows easier assignment on file loading, keeps curve- specific runtime data grouped and saves couple of bytes in Object for non-curve types. -- svn merge -r57938:57939 ^/branches/soc-2013-depsgraph_mt svn merge -r57957:57958^/branches/soc-2013-depsgraph_mt
2013-08-19 09:25:24 +00:00
if (ob->curve_cache) {
disp = ob->curve_cache->disp;
}
return CDDM_from_curve_displist(ob, &disp);
- Fixed trouble with rendering curves with disabled modifiers, which are disabled for realtime displaying but enabled for rendering. - Calculate tex space for curves before modifiers applying.
2010-03-08 13:49:13 +00:00
}
Fix #33752: UV Orco coordinates were wrong for Cycles (and other external render engines). Replaced generating orco_index by filling the UV loop data directly which is easier and all that needed to be done anyway.
2013-01-10 17:37:17 +00:00
DerivedMesh *CDDM_from_curve_displist(Object *ob, ListBase *dispbase)
support for curve orco uv's as UV's in cycles. ideally these would be used as generated coordinates, but this is tricly because cycles calculates its own orco's and doesnt know about curve settings.
2012-07-31 13:43:26 +00:00
{
Construct orco UV layer for curve when applying constructive modifier Also construct orco uv layer when converting curve to a mesh. This makes it possible to preserve automatically generated coordinates ("use uv for mapping" option) when using constructive modifiers or converting curve to the mesh. With cycles nothing special is needed to preserve texture mapping after such operations, in blender internal you'll need to change texture mapping from Generated to UV. This feature is useful on it's own and also would help in potential switch 3d viewport to always use DM to draw objects, which would help making drawing more thread-safe.
2013-06-20 13:27:48 +00:00
Curve *cu = (Curve *) ob->data;
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
DerivedMesh *dm;
CDDerivedMesh *cddm;
MVert *allvert;
MEdge *alledge;
=bmesh= merge from trunk at r36153
2011-04-15 01:19:13 +00:00
MLoop *allloop;
MPoly *allpoly;
Construct orco UV layer for curve when applying constructive modifier Also construct orco uv layer when converting curve to a mesh. This makes it possible to preserve automatically generated coordinates ("use uv for mapping" option) when using constructive modifiers or converting curve to the mesh. With cycles nothing special is needed to preserve texture mapping after such operations, in blender internal you'll need to change texture mapping from Generated to UV. This feature is useful on it's own and also would help in potential switch 3d viewport to always use DM to draw objects, which would help making drawing more thread-safe.
2013-06-20 13:27:48 +00:00
MLoopUV *alluv = NULL;
fix for crash converting a curve into a mesh (Alt+C conversion), this would crash on entering editmode. now curves convert to polygons directly, rather then faces, and polygons after.
2012-02-03 04:58:55 +00:00
int totvert, totedge, totloop, totpoly;
Construct orco UV layer for curve when applying constructive modifier Also construct orco uv layer when converting curve to a mesh. This makes it possible to preserve automatically generated coordinates ("use uv for mapping" option) when using constructive modifiers or converting curve to the mesh. With cycles nothing special is needed to preserve texture mapping after such operations, in blender internal you'll need to change texture mapping from Generated to UV. This feature is useful on it's own and also would help in potential switch 3d viewport to always use DM to draw objects, which would help making drawing more thread-safe.
2013-06-20 13:27:48 +00:00
bool use_orco_uv = (cu->flag & CU_UV_ORCO) != 0;
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
Cleanup: ws
2015-07-15 12:08:32 +10:00
if (BKE_mesh_nurbs_displist_to_mdata(
ob, dispbase, &allvert, &totvert, &alledge,
&totedge, &allloop, &allpoly, (use_orco_uv) ? &alluv : NULL,
&totloop, &totpoly) != 0)
code cleanup: naming - BKE_mesh_*
2012-05-05 21:28:12 +00:00
{
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
/* Error initializing mdata. This often happens when curve is empty */
part 1 of merge from trunk at r30358; it compiles, but doesn't link quite yet :)
2010-07-19 04:44:37 +00:00
return CDDM_new(0, 0, 0, 0, 0);
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
}
fix for crash converting a curve into a mesh (Alt+C conversion), this would crash on entering editmode. now curves convert to polygons directly, rather then faces, and polygons after.
2012-02-03 04:58:55 +00:00
dm = CDDM_new(totvert, totedge, 0, totloop, totpoly);
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
dm->deformedOnly = 1;
modifier stack: lazy initialize normals many modifiers were calculating normals, when those normals were ignored by the next modifier. now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback. Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
2013-05-30 17:36:43 +00:00
dm->dirty |= DM_DIRTY_NORMALS;
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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
cddm = (CDDerivedMesh *)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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
memcpy(cddm->mvert, allvert, totvert * sizeof(MVert));
memcpy(cddm->medge, alledge, totedge * sizeof(MEdge));
memcpy(cddm->mloop, allloop, totloop * sizeof(MLoop));
memcpy(cddm->mpoly, allpoly, totpoly * sizeof(MPoly));
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
Construct orco UV layer for curve when applying constructive modifier Also construct orco uv layer when converting curve to a mesh. This makes it possible to preserve automatically generated coordinates ("use uv for mapping" option) when using constructive modifiers or converting curve to the mesh. With cycles nothing special is needed to preserve texture mapping after such operations, in blender internal you'll need to change texture mapping from Generated to UV. This feature is useful on it's own and also would help in potential switch 3d viewport to always use DM to draw objects, which would help making drawing more thread-safe.
2013-06-20 13:27:48 +00:00
if (alluv) {
const char *uvname = "Orco";
CustomData_add_layer_named(&cddm->dm.polyData, CD_MTEXPOLY, CD_DEFAULT, NULL, totpoly, uvname);
CustomData_add_layer_named(&cddm->dm.loopData, CD_MLOOPUV, CD_ASSIGN, alluv, totloop, uvname);
}
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
MEM_freeN(allvert);
MEM_freeN(alledge);
=bmesh= merge from trunk at r36153
2011-04-15 01:19:13 +00:00
MEM_freeN(allloop);
MEM_freeN(allpoly);
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
return dm;
}
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
Cleanup: ws
2015-07-15 12:08:32 +10:00
static void loops_to_customdata_corners(
BMesh *bm, CustomData *facedata,
int cdindex, const BMLoop *l3[3],
int numCol, int numTex)
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
{
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
const BMLoop *l;
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
BMFace *f = l3[0]->f;
MTFace *texface;
MTexPoly *texpoly;
MCol *mcol;
MLoopCol *mloopcol;
MLoopUV *mloopuv;
Renaming CD_WEIGHT_MCOL/MLOOPCOL and their masks from WEIGHT to PREVIEW, as this layer is now also used for various preview tasks in Object mode. “Cleanup” commit, no functional changes.
2012-03-22 08:41:50 +00:00
int i, j, hasPCol = CustomData_has_layer(&bm->ldata, CD_PREVIEW_MLOOPCOL);
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
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < numTex; i++) {
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
texface = CustomData_get_n(facedata, CD_MTFACE, cdindex, i);
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
texpoly = CustomData_bmesh_get_n(&bm->pdata, f->head.data, CD_MTEXPOLY, i);
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
Code Cleanup: macro for copying polygon settings
2012-02-08 09:02:10 +00:00
ME_MTEXFACE_CPY(texface, texpoly);
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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
for (j = 0; j < 3; j++) {
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
l = l3[j];
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
mloopuv = CustomData_bmesh_get_n(&bm->ldata, l->head.data, CD_MLOOPUV, i);
Code Cleanup: use vector functions for copying / adding UV's
2012-02-05 13:25:42 +00:00
copy_v2_v2(texface->uv[j], mloopuv->uv);
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
}
}
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < numCol; i++) {
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
mcol = CustomData_get_n(facedata, CD_MCOL, cdindex, i);
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (j = 0; j < 3; j++) {
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
l = l3[j];
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
mloopcol = CustomData_bmesh_get_n(&bm->ldata, l->head.data, CD_MLOOPCOL, i);
swap BMLoopCol r/b color, requires subversion bump. old mesh MCol 'r' was blue, 'b' was red, but theres no reason to keep this for bmesh with MLoopCol. Loading old files works, saving legacy format works too. What wont work is loading a file after this revision and loading it in an older revision since the bmesh merge. (it wont crash but the blue and red will be swapped on vertex color layers).
2012-03-17 20:39:28 +00:00
MESH_MLOOPCOL_TO_MCOL(mloopcol, &mcol[j]);
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
}
}
brought weight paint back.
2009-08-31 15:57:13 +00:00
Renaming CD_WEIGHT_MCOL/MLOOPCOL and their masks from WEIGHT to PREVIEW, as this layer is now also used for various preview tasks in Object mode. “Cleanup” commit, no functional changes.
2012-03-22 08:41:50 +00:00
if (hasPCol) {
mcol = CustomData_get(facedata, cdindex, CD_PREVIEW_MCOL);
brought weight paint back.
2009-08-31 15:57:13 +00:00
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (j = 0; j < 3; j++) {
brought weight paint back.
2009-08-31 15:57:13 +00:00
l = l3[j];
Renaming CD_WEIGHT_MCOL/MLOOPCOL and their masks from WEIGHT to PREVIEW, as this layer is now also used for various preview tasks in Object mode. “Cleanup” commit, no functional changes.
2012-03-22 08:41:50 +00:00
mloopcol = CustomData_bmesh_get(&bm->ldata, l->head.data, CD_PREVIEW_MLOOPCOL);
swap BMLoopCol r/b color, requires subversion bump. old mesh MCol 'r' was blue, 'b' was red, but theres no reason to keep this for bmesh with MLoopCol. Loading old files works, saving legacy format works too. What wont work is loading a file after this revision and loading it in an older revision since the bmesh merge. (it wont crash but the blue and red will be swapped on vertex color layers).
2012-03-17 20:39:28 +00:00
MESH_MLOOPCOL_TO_MCOL(mloopcol, &mcol[j]);
brought weight paint back.
2009-08-31 15:57:13 +00:00
}
}
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
}
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
/* used for both editbmesh and bmesh */
Cleanup: ws
2015-07-15 12:08:32 +10:00
static DerivedMesh *cddm_from_bmesh_ex(
struct BMesh *bm, const bool use_mdisps,
/* EditBMesh vars for use_tessface */
const bool use_tessface,
const int em_tottri, const BMLoop *(*em_looptris)[3])
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
{
fix for remesh (infact any modifier that uses tessface's) not displaying geometry in editmode. the bug was in CDDM_from_BMEditMesh which would create tessfaces even when use_tessface==FALSE.
2012-02-07 03:03:09 +00:00
DerivedMesh *dm = CDDM_new(bm->totvert,
bm->totedge,
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
use_tessface ? em_tottri : 0,
fix for remesh (infact any modifier that uses tessface's) not displaying geometry in editmode. the bug was in CDDM_from_BMEditMesh which would create tessfaces even when use_tessface==FALSE.
2012-02-07 03:03:09 +00:00
bm->totloop,
bm->totface);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
minor bmesh improvements - use 2 omp sections for vert -> (edge, face) selection flushing. - dont use face-loop iterator for cddm_from_bmesh_ex conversion to give some speedup (some modifiers use this). - use float(*)[3] for functions that return coords.
2012-12-21 07:28:14 +00:00
BMIter iter;
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
BMVert *eve;
BMEdge *eed;
BMFace *efa;
MVert *mvert = cddm->mvert;
MEdge *medge = cddm->medge;
MFace *mface = cddm->mface;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
MLoop *mloop = cddm->mloop;
MPoly *mpoly = cddm->mpoly;
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
int numCol = CustomData_number_of_layers(&bm->ldata, CD_MLOOPCOL);
int numTex = CustomData_number_of_layers(&bm->pdata, CD_MTEXPOLY);
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
int *index, add_orig;
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
CustomDataMask mask;
set mloop edge and vertex as unsigned ints since face/edge reference verts as unsigned ints too
2011-12-28 04:43:29 +00:00
unsigned int i, j;
=bmesh= fixed edge creasing for subsurf
2011-03-27 03:29:27 +00:00
don't store bevel weights or edge crease customdata layers in editmode unless they are needed. configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
2013-01-10 04:43:31 +00:00
const int cd_vert_bweight_offset = CustomData_get_offset(&bm->vdata, CD_BWEIGHT);
const int cd_edge_bweight_offset = CustomData_get_offset(&bm->edata, CD_BWEIGHT);
const int cd_edge_crease_offset = CustomData_get_offset(&bm->edata, CD_CREASE);
=bmesh= fixed edge creasing for subsurf
2011-03-27 03:29:27 +00:00
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
dm->deformedOnly = 1;
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
fix own error in recent smoothview cleanup, also correct some cross references in bmesh docs.
2012-08-17 14:43:20 +00:00
/* don't add origindex layer if one already exists */
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
add_orig = !CustomData_has_layer(&bm->pdata, CD_ORIGINDEX);
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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
mask = use_mdisps ? CD_MASK_DERIVEDMESH | CD_MASK_MDISPS : CD_MASK_DERIVEDMESH;
=bmesh= modifiers can now be applied with shapekeys
2011-04-15 05:20:18 +00:00
style cleanup: comment blocks
2012-03-09 18:28:30 +00:00
/* don't process shapekeys, we only feed them through the modifier stack as needed,
* e.g. for applying modifiers or the like*/
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
mask &= ~CD_MASK_SHAPEKEY;
CustomData_merge(&bm->vdata, &dm->vertData, mask,
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
CD_CALLOC, dm->numVertData);
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
CustomData_merge(&bm->edata, &dm->edgeData, mask,
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
CD_CALLOC, dm->numEdgeData);
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
CustomData_merge(&bm->ldata, &dm->loopData, mask,
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
CD_CALLOC, dm->numLoopData);
fix for editmode bmesh bug - found by testing script. incorrect flag handling in CDDM_from_BMEditMesh() broke editmode deform verts (they would never be copied), issue was exposed when re-aligning layer values with trunk.
2012-01-18 14:52:47 +00:00
CustomData_merge(&bm->pdata, &dm->polyData, mask,
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
CD_CALLOC, dm->numPolyData);
minor bmesh improvements - use 2 omp sections for vert -> (edge, face) selection flushing. - dont use face-loop iterator for cddm_from_bmesh_ex conversion to give some speedup (some modifiers use this). - use float(*)[3] for functions that return coords.
2012-12-21 07:28:14 +00:00
fix own error in recent smoothview cleanup, also correct some cross references in bmesh docs.
2012-08-17 14:43:20 +00:00
/* add tessellation mface layers */
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
if (use_tessface) {
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
CustomData_from_bmeshpoly(&dm->faceData, &dm->polyData, &dm->loopData, em_tottri);
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
}
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
index = dm->getVertDataArray(dm, CD_ORIGINDEX);
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
BM_ITER_MESH_INDEX (eve, &iter, bm, BM_VERTS_OF_MESH, i) {
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
MVert *mv = &mvert[i];
replace bmesh specific macros with math functions, also some pedantic formatting edits.
2011-11-07 09:02:10 +00:00
copy_v3_v3(mv->co, eve->co);
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
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
BM_elem_index_set(eve, i); /* set_inline */
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
Fix "[#29036] Crash on solidify" and a few misc subsurf and derived mesh bugs that were blocking correct functionality of "apply modifier to editcage" when you have a subsurf + solidify modifier on the stack
2011-10-27 12:17:02 +00:00
normal_float_to_short_v3(mv->no, eve->no);
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
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
mv->flag = BM_vert_flag_to_mflag(eve);
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
don't store bevel weights or edge crease customdata layers in editmode unless they are needed. configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
2013-01-10 04:43:31 +00:00
if (cd_vert_bweight_offset != -1) mv->bweight = BM_ELEM_CD_GET_FLOAT_AS_UCHAR(eve, cd_vert_bweight_offset);
=bmesh= fixed edge creasing for subsurf
2011-03-27 03:29:27 +00:00
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
if (add_orig) *index++ = i;
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
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
CustomData_from_bmesh_block(&bm->vdata, &dm->vertData, eve->head.data, i);
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
}
prepare for flagging the bmesh has having invalid index values, so we can skip looping over all elements if its already valid. - went over every BM_SetIndex call and added comments about its use, if its setting dirty values or correct ones. - replace loops over all elements _just_ to set index values, with a new function, BM_ElemIndex_Ensure(...), this will eventually only initialize values when they are dirty.
2011-11-16 12:38:40 +00:00
bm->elem_index_dirty &= ~BM_VERT;
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
index = dm->getEdgeDataArray(dm, CD_ORIGINDEX);
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
BM_ITER_MESH_INDEX (eed, &iter, bm, BM_EDGES_OF_MESH, i) {
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
MEdge *med = &medge[i];
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
BM_elem_index_set(eed, i); /* set_inline */
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
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
med->v1 = BM_elem_index_get(eed->v1);
med->v2 = BM_elem_index_get(eed->v2);
=bmesh= fixed edge creasing for subsurf
2011-03-27 03:29:27 +00:00
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
med->flag = BM_edge_flag_to_mflag(eed);
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
fix [#31489] EdgeSplit modifier prevents All Edge to be work correctly since 2.63 bmesh regression where the edge-draw flag was cleared when bmesh modifiers were used.
2012-05-22 07:26:45 +00:00
/* handle this differently to editmode switching,
* only enable draw for single user edges rather then calculating angle */
if ((med->flag & ME_EDGEDRAW) == 0) {
if (eed->l && eed->l == eed->l->radial_next) {
med->flag |= ME_EDGEDRAW;
}
}
don't store bevel weights or edge crease customdata layers in editmode unless they are needed. configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
2013-01-10 04:43:31 +00:00
if (cd_edge_crease_offset != -1) med->crease = BM_ELEM_CD_GET_FLOAT_AS_UCHAR(eed, cd_edge_crease_offset);
if (cd_edge_bweight_offset != -1) med->bweight = BM_ELEM_CD_GET_FLOAT_AS_UCHAR(eed, cd_edge_bweight_offset);
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
CustomData_from_bmesh_block(&bm->edata, &dm->edgeData, eed->head.data, i);
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
if (add_orig) *index++ = i;
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
}
prepare for flagging the bmesh has having invalid index values, so we can skip looping over all elements if its already valid. - went over every BM_SetIndex call and added comments about its use, if its setting dirty values or correct ones. - replace loops over all elements _just_ to set index values, with a new function, BM_ElemIndex_Ensure(...), this will eventually only initialize values when they are dirty.
2011-11-16 12:38:40 +00:00
bm->elem_index_dirty &= ~BM_EDGE;
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
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
/* avoid this where possiblem, takes extra memory */
if (use_tessface) {
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
BM_mesh_elem_index_ensure(bm, BM_FACE);
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
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
index = dm->getTessFaceDataArray(dm, CD_ORIGINDEX);
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
for (i = 0; i < dm->numTessFaceData; i++) {
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
MFace *mf = &mface[i];
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
const BMLoop **l = em_looptris[i];
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
efa = l[0]->f;
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
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
mf->v1 = BM_elem_index_get(l[0]->v);
mf->v2 = BM_elem_index_get(l[1]->v);
mf->v3 = BM_elem_index_get(l[2]->v);
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
mf->v4 = 0;
mf->mat_nr = efa->mat_nr;
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
mf->flag = BM_face_flag_to_mflag(efa);
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
/* map mfaces to polygons in the same cddm intentionally */
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
*index++ = BM_elem_index_get(efa);
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
loops_to_customdata_corners(bm, &dm->faceData, i, l, numCol, numTex);
test_index_face(mf, &dm->faceData, i, 3);
}
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
}
(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
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
index = CustomData_get_layer(&dm->polyData, CD_ORIGINDEX);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
j = 0;
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
BM_ITER_MESH_INDEX (efa, &iter, bm, BM_FACES_OF_MESH, i) {
minor bmesh improvements - use 2 omp sections for vert -> (edge, face) selection flushing. - dont use face-loop iterator for cddm_from_bmesh_ex conversion to give some speedup (some modifiers use this). - use float(*)[3] for functions that return coords.
2012-12-21 07:28:14 +00:00
BMLoop *l_iter;
BMLoop *l_first;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
MPoly *mp = &mpoly[i];
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
BM_elem_index_set(efa, i); /* set_inline */
argument for CDDM_from_BMEditMesh() so creating tessface data is optional, no functional changes since all callers use this so far.
2012-01-18 15:09:27 +00:00
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
mp->totloop = efa->len;
code refactor, function renaming for bmesh. These changes are to make the bmesh api more consistent and easier to learn, grouping similar functions which is convenient for autocomplete. This uses similar convention to RNA. * use face/loop/edge/vert as a prefix for functions. * use 'elem' as a prefix too for functions that can take any type with a BMHeader. * changed from camel case to underscore separated (like RNA).
2012-02-12 10:51:45 +00:00
mp->flag = BM_face_flag_to_mflag(efa);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
mp->loopstart = j;
mp->mat_nr = efa->mat_nr;
minor bmesh improvements - use 2 omp sections for vert -> (edge, face) selection flushing. - dont use face-loop iterator for cddm_from_bmesh_ex conversion to give some speedup (some modifiers use this). - use float(*)[3] for functions that return coords.
2012-12-21 07:28:14 +00:00
l_iter = l_first = BM_FACE_FIRST_LOOP(efa);
do {
mloop->v = BM_elem_index_get(l_iter->v);
mloop->e = BM_elem_index_get(l_iter->e);
CustomData_from_bmesh_block(&bm->ldata, &dm->loopData, l_iter->head.data, j);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
Various fixes/improvements regarding BMesh's elem_index_dirty and BM_LOOP handling. Most notably, BM_LOOP and BM_FACE index recompute should now be fully decoupled.
2014-04-15 16:18:27 +02:00
BM_elem_index_set(l_iter, j); /* set_inline */
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
j++;
mloop++;
minor bmesh improvements - use 2 omp sections for vert -> (edge, face) selection flushing. - dont use face-loop iterator for cddm_from_bmesh_ex conversion to give some speedup (some modifiers use this). - use float(*)[3] for functions that return coords.
2012-12-21 07:28:14 +00:00
} while ((l_iter = l_iter->next) != l_first);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
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
CustomData_from_bmesh_block(&bm->pdata, &dm->polyData, efa->head.data, i);
use bmesh for loop macros for looping over mesh verts/edges/faces
2013-08-01 18:33:35 +00:00
if (add_orig) *index++ = i;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
}
Various fixes/improvements regarding BMesh's elem_index_dirty and BM_LOOP handling. Most notably, BM_LOOP and BM_FACE index recompute should now be fully decoupled.
2014-04-15 16:18:27 +02:00
bm->elem_index_dirty &= ~(BM_FACE | BM_LOOP);
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
don't store bevel weights or edge crease customdata layers in editmode unless they are needed. configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
2013-01-10 04:43:31 +00:00
dm->cd_flag = BM_mesh_cd_flag_from_bmesh(bm);
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
return dm;
}
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
struct DerivedMesh *CDDM_from_bmesh(struct BMesh *bm, const bool use_mdisps)
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
{
Cleanup: ws
2015-07-15 12:08:32 +10:00
return cddm_from_bmesh_ex(
bm, use_mdisps, false,
/* these vars are for editmesh only */
0, NULL);
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
}
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
DerivedMesh *CDDM_from_editbmesh(BMEditMesh *em, const bool use_mdisps, const bool use_tessface)
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
{
Cleanup: ws
2015-07-15 12:08:32 +10:00
return cddm_from_bmesh_ex(
em->bm, use_mdisps,
/* editmesh */
use_tessface, em->tottri, (const BMLoop *(*)[3])em->looptris);
add CDDM_from_bmesh(), avoids using BMEditMesh in modifiers.
2012-10-24 07:24:11 +00:00
}
remove CDDM_copy second argument, added CDDM_copy_from_tessface instead. this function caused too many conflicts and in most cases was zero anyway.
2012-01-29 21:59:47 +00:00
static DerivedMesh *cddm_copy_ex(DerivedMesh *source, int faces_from_tessfaces)
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
CDDerivedMesh *cddm = cdDM_create("CDDM_copy cddm");
DerivedMesh *dm = &cddm->dm;
int numVerts = source->numVertData;
int numEdges = source->numEdgeData;
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
int numTessFaces = source->numTessFaceData;
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
int numLoops = source->numLoopData;
int numPolys = source->numPolyData;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
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
/* ensure these are created if they are made on demand */
source->getVertDataArray(source, CD_ORIGINDEX);
source->getEdgeDataArray(source, CD_ORIGINDEX);
Merge with trunk/2.5 at r25563 Most likely will not compile for others, I'd appreciate any build errors and missing files reports (I can never seem to get everything committed and all the build systems working without help). Porting over the sculpt/multires tools was a breeze, thanks goes to brecht for a design that didn't exclude ngons and was easy to port. Note that I've not tested externally-backed multires file support yet. Also, I still need to write version patch code for some cases. Some notes: * Like trunk, topological changes don't update multires right, so e.g. subdivide will duplicate multires data on the new faces, instead of subdividing it. * If you set the debug value (ctrl-alt-d) to 1 it'll turn on my experiments in speeding up sculpting on higher-res multires meshes (but note it makes partial redraw not completely accurate). * There's a bug where you have to go through editmode to get out of sculpt mode, not sure if I inherited or created this myself.
2010-01-05 22:33:41 +00:00
source->getTessFaceDataArray(source, CD_ORIGINDEX);
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
source->getPolyDataArray(source, CD_ORIGINDEX);
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
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* this initializes dm, and copies all non mvert/medge/mface layers */
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
DM_from_template(dm, source, DM_TYPE_CDDM, numVerts, numEdges, numTessFaces,
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
numLoops, numPolys);
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 22:09:57 +00:00
dm->deformedOnly = source->deformedOnly;
don't store bevel weights or edge crease customdata layers in editmode unless they are needed. configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
2013-01-10 04:43:31 +00:00
dm->cd_flag = source->cd_flag;
Fix [#30234] Various problems with CD layers and tesselation, related to modifiers stack. Should also fix [#30266], [#29451], and partly [#30316]. Here are the changes made by this commit: * It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed). * It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts. * At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation). * Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers). * Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one). Note: some pieces of old code are just #if 0’ed, will clean them later.
2012-03-18 22:06:57 +00:00
dm->dirty = source->dirty;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
CustomData_copy_data(&source->vertData, &dm->vertData, 0, 0, numVerts);
CustomData_copy_data(&source->edgeData, &dm->edgeData, 0, 0, numEdges);
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_copy_data(&source->faceData, &dm->faceData, 0, 0, numTessFaces);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* now add mvert/medge/mface layers */
cddm->mvert = source->dupVertArray(source);
cddm->medge = source->dupEdgeArray(source);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
cddm->mface = source->dupTessFaceArray(source);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +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
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_ASSIGN, cddm->mvert, numVerts);
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_ASSIGN, cddm->medge, numEdges);
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_ASSIGN, cddm->mface, numTessFaces);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
made subsurf object mode conversion faster, though still needs a bit more work
2009-09-15 15:32:09 +00:00
if (!faces_from_tessfaces)
DM_DupPolys(source, dm);
code cleanup: white space, spelling & ';;' end of lines.
2012-02-25 16:04:03 +00:00
else
made subsurf object mode conversion faster, though still needs a bit more work
2009-09-15 15:32:09 +00:00
CDDM_tessfaces_to_faces(dm);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
return dm;
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
}
remove CDDM_copy second argument, added CDDM_copy_from_tessface instead. this function caused too many conflicts and in most cases was zero anyway.
2012-01-29 21:59:47 +00:00
DerivedMesh *CDDM_copy(DerivedMesh *source)
{
return cddm_copy_ex(source, 0);
}
DerivedMesh *CDDM_copy_from_tessface(DerivedMesh *source)
{
return cddm_copy_ex(source, 1);
}
[#24267] Hook fails after Solidify Solidify modifier wasn't assigning origindex values. - BLI_math.h array functions: range_vni(), mul_vn_fl(), mul_vn_vn_fl(), add_vn_vn(), fill_vni(). - define 'AT' as __FILE__ ":" STRINGIFY(__LINE__), useful for quick debug prints.
2010-10-20 09:18:55 +00:00
/* note, the CD_ORIGINDEX layers are all 0, so if there is a direct
Spelling Cleanup
2012-03-01 12:20:18 +00:00
* relationship between mesh data this needs to be set by the caller. */
Fix T46215: Explode modifier looses textures
2015-09-23 22:57:00 +10:00
DerivedMesh *CDDM_from_template_ex(
Cleanup: ws
2015-07-15 12:08:32 +10:00
DerivedMesh *source,
int numVerts, int numEdges, int numTessFaces,
Fix T46215: Explode modifier looses textures
2015-09-23 22:57:00 +10:00
int numLoops, int numPolys,
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
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
CDDerivedMesh *cddm = cdDM_create("CDDM_from_template dest");
DerivedMesh *dm = &cddm->dm;
Fix #22673: crash with solidify + subsurf + array modifier in edit mode.
2010-07-27 12:01:40 +00:00
/* ensure these are created if they are made on demand */
source->getVertDataArray(source, CD_ORIGINDEX);
source->getEdgeDataArray(source, CD_ORIGINDEX);
merge with trunk at r31523
2010-09-04 05:31:25 +00:00
source->getTessFaceDataArray(source, CD_ORIGINDEX);
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
source->getPolyDataArray(source, CD_ORIGINDEX);
Fix #22673: crash with solidify + subsurf + array modifier in edit mode.
2010-07-27 12:01:40 +00:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* this does a copy of all non mvert/medge/mface layers */
Fix T46215: Explode modifier looses textures
2015-09-23 22:57:00 +10:00
DM_from_template_ex(
dm, source, DM_TYPE_CDDM,
numVerts, numEdges, numTessFaces,
numLoops, numPolys,
mask);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* now add mvert/medge/mface layers */
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
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_CALLOC, NULL, numVerts);
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_CALLOC, NULL, numTessFaces);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
CustomData_add_layer(&dm->loopData, CD_MLOOP, CD_CALLOC, NULL, numLoops);
CustomData_add_layer(&dm->polyData, CD_MPOLY, CD_CALLOC, NULL, numPolys);
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
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!CustomData_get_layer(&dm->vertData, CD_ORIGINDEX))
Sculpt: derivedmesh no longer created CD_ORIGINDEX layer when there is no modifier, saving some memory.
2009-11-04 20:23:48 +00:00
CustomData_add_layer(&dm->vertData, CD_ORIGINDEX, CD_CALLOC, NULL, numVerts);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!CustomData_get_layer(&dm->edgeData, CD_ORIGINDEX))
Sculpt: derivedmesh no longer created CD_ORIGINDEX layer when there is no modifier, saving some memory.
2009-11-04 20:23:48 +00:00
CustomData_add_layer(&dm->edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (!CustomData_get_layer(&dm->faceData, CD_ORIGINDEX))
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_add_layer(&dm->faceData, CD_ORIGINDEX, CD_CALLOC, NULL, numTessFaces);
Sculpt: derivedmesh no longer created CD_ORIGINDEX layer when there is no modifier, saving some memory.
2009-11-04 20:23:48 +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
cddm->mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
cddm->mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
cddm->mloop = CustomData_get_layer(&dm->loopData, CD_MLOOP);
cddm->mpoly = CustomData_get_layer(&dm->polyData, CD_MPOLY);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
return dm;
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
}
Fix T46215: Explode modifier looses textures
2015-09-23 22:57:00 +10:00
DerivedMesh *CDDM_from_template(
DerivedMesh *source,
int numVerts, int numEdges, int numTessFaces,
int numLoops, int numPolys)
{
return CDDM_from_template_ex(
source, numVerts, numEdges, numTessFaces,
numLoops, numPolys,
CD_MASK_DERIVEDMESH);
}
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 CDDM_apply_vert_coords(DerivedMesh *dm, float (*vertCoords)[3])
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MVert *vert;
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 i;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* this will just return the pointer if it wasn't a referenced layer */
Fix a bug in CustomData_duplicate_referenced_layer(_named) functions: MEM_dupallocN does not work with complex layers like CD_MDEFORMVERT ones, so rather use copy func when available.
2011-12-19 08:26:53 +00:00
vert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
cddm->mvert = vert;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
for (i = 0; i < dm->numVertData; ++i, ++vert)
replace VECCOPY with copy_v3_v3, same for 2d copy, also added vec copy functions for int & char.
2011-11-07 01:38:32 +00:00
copy_v3_v3(vert->co, vertCoords[i]);
modifier stack: lazy initialize normals many modifiers were calculating normals, when those normals were ignored by the next modifier. now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback. Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
2013-05-30 17:36:43 +00:00
cddm->dm.dirty |= DM_DIRTY_NORMALS;
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
void CDDM_apply_vert_normals(DerivedMesh *dm, short (*vertNormals)[3])
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MVert *vert;
int i;
/* this will just return the pointer if it wasn't a referenced layer */
Fix a bug in CustomData_duplicate_referenced_layer(_named) functions: MEM_dupallocN does not work with complex layers like CD_MDEFORMVERT ones, so rather use copy func when available.
2011-12-19 08:26:53 +00:00
vert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
cddm->mvert = vert;
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
for (i = 0; i < dm->numVertData; ++i, ++vert)
replace VECCOPY -> copy_v3_v3, added copy_v*_v*_short too for typesafe copying, some parts of the code are copying float -> short normals without scaling. fix coming next.
2011-09-12 04:14:12 +00:00
copy_v3_v3_short(vert->no, vertNormals[i]);
modifier stack: lazy initialize normals many modifiers were calculating normals, when those normals were ignored by the next modifier. now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback. Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
2013-05-30 17:36:43 +00:00
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
}
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
void CDDM_calc_normals_mapping_ex(DerivedMesh *dm, const bool only_face_normals)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
=bmesh= merge from trunk at r36153
2011-04-15 01:19:13 +00:00
float (*face_nors)[3] = NULL;
alternative fix for [#29338], now dont duplicate the vertex layer when calculating normals, instead only calculate face normals.
2011-12-07 01:12:53 +00:00
correct assertion error (clear dirty normal flag when there are no vertices)
2013-06-25 14:31:52 +00:00
if (dm->numVertData == 0) {
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
return;
}
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
alternative fix for [#29338], now dont duplicate the vertex layer when calculating normals, instead only calculate face normals.
2011-12-07 01:12:53 +00:00
/* now we skip calculating vertex normals for referenced layer,
* no need to duplicate verts.
* WATCH THIS, bmesh only change!,
* need to take care of the side effects here - campbell */
Style Cleanup: remove preprocessor indentation (updated wiki style guide too)
2013-12-22 14:11:10 +11:00
#if 0
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
/* we don't want to overwrite any referenced layers */
Fix a bug in CustomData_duplicate_referenced_layer(_named) functions: MEM_dupallocN does not work with complex layers like CD_MDEFORMVERT ones, so rather use copy func when available.
2011-12-19 08:26:53 +00:00
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
Style Cleanup: remove preprocessor indentation (updated wiki style guide too)
2013-12-22 14:11:10 +11:00
#endif
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
Don't create MFace's when calculating normals Instead only create MFace layer when its requested
2015-07-17 20:14:17 +10:00
#if 0
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
if (dm->numTessFaceData == 0) {
style cleanup - spelling - turns out we had tessellation spelt wrong all over. - use \directive for doxy (not @directive) - remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
2012-03-02 16:05:54 +00:00
/* No tessellation on this mesh yet, need to calculate one.
ensure defoem DM has tessface data for the few places that need it. also add a workaround for CDDM_recalc_tesselation_ex() which would add a CD_NORMAL to dm->fdata and then overwrite immediate
2012-01-19 19:23:25 +00:00
*
* Important not to update face normals from polys since it
fix incorrect assert for mask face checking, also correct own bad spelling
2012-07-18 11:01:23 +00:00
* interferes with assigning the new normal layer in the following code.
ensure defoem DM has tessface data for the few places that need it. also add a workaround for CDDM_recalc_tesselation_ex() which would add a CD_NORMAL to dm->fdata and then overwrite immediate
2012-01-19 19:23:25 +00:00
*/
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
CDDM_recalc_tessellation_ex(dm, false);
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
}
else {
remove CD_POLYINDEX customdata layer: reported as [#29376] BMESH_TODO: remove tessface CD_ORIGINDEX layer for a single mesh there could be 3 origindex mappings stored, one on the polygons and 2 on the tessfaces. (CD_POLYINDEX and CD_ORIGINDEX). as Andrew suggests, now tessfaces (which are really a cache of polygons), using origindex to point to polygons on the same derived mesh, and polygons only store the original index values.
2012-10-30 19:20:17 +00:00
/* A tessellation already exists, it should always have a CD_ORIGINDEX */
BLI_assert(CustomData_has_layer(&dm->faceData, CD_ORIGINDEX));
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_free_layers(&dm->faceData, CD_NORMAL, dm->numTessFaceData);
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
}
Don't create MFace's when calculating normals Instead only create MFace layer when its requested
2015-07-17 20:14:17 +10:00
#endif
Add CD_POLYINDEX layer to reduce need for retesselations
2011-11-13 15:13:59 +00:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
face_nors = MEM_mallocN(sizeof(*face_nors) * dm->numPolyData, "face_nors");
ngons draw with uniform normals in object mode now, I had this code disabled for speed (it was being called when it didnt need to), but for CDDM meshes without face normal layers this should still be called.
2012-03-18 06:49:32 +00:00
=bmesh= merge from trunk at r36153
2011-04-15 01:19:13 +00:00
/* calculate face normals */
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
BKE_mesh_calc_normals_poly(
Add functions to compute normals (verts, polys and loops ones) for a given shapekey. Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and loop normals of a given shapekey. This will be used e.g. in FBX exporter (shapekeys need normal data too). Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D1510
2015-10-12 20:12:55 +02:00
cddm->mvert, NULL, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
dm->numLoopData, dm->numPolyData, face_nors,
Cleanup: ws
2015-07-15 12:08:32 +10:00
only_face_normals);
ngons draw with uniform normals in object mode now, I had this code disabled for speed (it was being called when it didnt need to), but for CDDM meshes without face normal layers this should still be called.
2012-03-18 06:49:32 +00:00
Add tessellation data to DerivedMesh (LoopTri) This stores loop indices into the loop array giving easier acess to data such as vertex-colors and UV's, removing the need to store an MFace duplicate of custom-data. This doesn't yet move all internal code from MFace to LoopTri just yet. Only applies to: - opengl drawing - sculpting (pbvh) - vertex/weight paint Thanks to @psy-fi for review, fixes and improvements to drawing!
2015-07-17 03:36:03 +10:00
CustomData_add_layer(&dm->polyData, CD_NORMAL, CD_ASSIGN, face_nors, dm->numPolyData);
modifier stack: lazy initialize normals many modifiers were calculating normals, when those normals were ignored by the next modifier. now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback. Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
2013-05-30 17:36:43 +00:00
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
ngons draw with uniform normals in object mode now, I had this code disabled for speed (it was being called when it didnt need to), but for CDDM meshes without face normal layers this should still be called.
2012-03-18 06:49:32 +00:00
}
void CDDM_calc_normals_mapping(DerivedMesh *dm)
{
/* use this to skip calculating normals on original vert's, this may need to be changed */
Cleanup: int/short to bool in BKE_cdderivedmesh.h functions (and TRUE/FALSE to true/false in code using them).
2014-01-23 14:50:50 +01:00
const bool only_face_normals = CustomData_is_referenced_layer(&dm->vertData, CD_MVERT);
argument to mesh_recalcTesselation to skip copying normals from polygons.
2012-01-19 17:51:52 +00:00
ngons draw with uniform normals in object mode now, I had this code disabled for speed (it was being called when it didnt need to), but for CDDM meshes without face normal layers this should still be called.
2012-03-18 06:49:32 +00:00
CDDM_calc_normals_mapping_ex(dm, only_face_normals);
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
}
remove CD_MASK_NORMAL from CD_MASK_DERIVEDMESH, bmesh merge included this but its not needed. Now add asserts to make sure this layer is only added once the modifier stack has been calculated. this saves normal layer being calculated whenver vertex normals need updating.
2013-05-30 18:09:19 +00:00
#if 0
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
/* bmesh note: this matches what we have in trunk */
void CDDM_calc_normals(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
float (*poly_nors)[3];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (dm->numVertData == 0) return;
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
/* we don't want to overwrite any referenced layers */
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
/* fill in if it exists */
poly_nors = CustomData_get_layer(&dm->polyData, CD_NORMAL);
if (!poly_nors) {
poly_nors = CustomData_add_layer(&dm->polyData, CD_NORMAL, CD_CALLOC, NULL, dm->numPolyData);
}
code cleanup: lots of calls to BKE_mesh_calc_normals_mapping were not using the mapping functionality. replace ED_mesh_calc_normals with BKE_mesh_calc_normals().
2013-05-28 14:23:07 +00:00
BKE_mesh_calc_normals_poly(cddm->mvert, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
solidify: dont add poly-normal layer to the derived mesh, since this is no longer a convention.
2013-06-12 09:35:02 +00:00
dm->numLoopData, dm->numPolyData, poly_nors, false);
modifier stack: lazy initialize normals many modifiers were calculating normals, when those normals were ignored by the next modifier. now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback. Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
2013-05-30 17:36:43 +00:00
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
}
remove CD_MASK_NORMAL from CD_MASK_DERIVEDMESH, bmesh merge included this but its not needed. Now add asserts to make sure this layer is only added once the modifier stack has been calculated. this saves normal layer being calculated whenver vertex normals need updating.
2013-05-30 18:09:19 +00:00
#else
/* poly normal layer is now only for final display */
void CDDM_calc_normals(DerivedMesh *dm)
{
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
/* we don't want to overwrite any referenced layers */
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
Add functions to compute normals (verts, polys and loops ones) for a given shapekey. Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and loop normals of a given shapekey. This will be used e.g. in FBX exporter (shapekeys need normal data too). Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D1510
2015-10-12 20:12:55 +02:00
BKE_mesh_calc_normals_poly(cddm->mvert, NULL, dm->numVertData, CDDM_get_loops(dm), CDDM_get_polys(dm),
solidify: dont add poly-normal layer to the derived mesh, since this is no longer a convention.
2013-06-12 09:35:02 +00:00
dm->numLoopData, dm->numPolyData, NULL, false);
remove CD_MASK_NORMAL from CD_MASK_DERIVEDMESH, bmesh merge included this but its not needed. Now add asserts to make sure this layer is only added once the modifier stack has been calculated. this saves normal layer being calculated whenver vertex normals need updating.
2013-05-30 18:09:19 +00:00
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
}
#endif
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
Make use/computation of lnors consistant. Issue was, when requesting (building) lnors for a mesh that has autosmooth disabled, one would expect to simply get vnors as lnors. Until now, it wasn't the case, which was bad e.g. for normal projections of loops in recent remap code (projecting along split loop normals when you would expect projection along vertex normals...). Also, removed the 'angle' parameter from RNA's `mesh.calc_normals_split`. This should *always* use mesh settings (both autosmooth and smoothresh), otherwise once again we'd get inconsistencies in some cases. Will update fbx and obj addons too.
2015-01-19 14:11:40 +01:00
void CDDM_calc_loop_normals(DerivedMesh *dm, const bool use_split_normals, const float split_angle)
Add Custom Loop Normals. This is the core code for it, tools (datatransfer and modifier) will come in next commits). RNA api is already there, though. See the code for details, but basically, we define, for each 'smooth fan' (which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal), a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store custom normal as two angular factors inside that space. This allows to have custom normals 'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer. Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals, and be converted back into storage format at the end. Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can be rather heavy with high poly meshes. Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
{
CDDM_calc_loop_normals_spacearr(dm, use_split_normals, split_angle, NULL);
}
/* #define DEBUG_CLNORS */
void CDDM_calc_loop_normals_spacearr(
DerivedMesh *dm, const bool use_split_normals, const float split_angle, MLoopNorSpaceArray *r_lnors_spacearr)
Split Normals I (1/5): basis for split normals (nearly nothing user-visible here): * Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf). EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit. * Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it (tessellation, rna access, etc.). * Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding this option is now incoherent, will be addressed in a separate commit. Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D365
2014-04-13 12:18:51 +02:00
{
MVert *mverts = dm->getVertArray(dm);
MEdge *medges = dm->getEdgeArray(dm);
MLoop *mloops = dm->getLoopArray(dm);
MPoly *mpolys = dm->getPolyArray(dm);
CustomData *ldata, *pdata;
float (*lnors)[3];
Add Custom Loop Normals. This is the core code for it, tools (datatransfer and modifier) will come in next commits). RNA api is already there, though. See the code for details, but basically, we define, for each 'smooth fan' (which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal), a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store custom normal as two angular factors inside that space. This allows to have custom normals 'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer. Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals, and be converted back into storage format at the end. Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can be rather heavy with high poly meshes. Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
short (*clnor_data)[2];
Split Normals I (1/5): basis for split normals (nearly nothing user-visible here): * Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf). EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit. * Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it (tessellation, rna access, etc.). * Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding this option is now incoherent, will be addressed in a separate commit. Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D365
2014-04-13 12:18:51 +02:00
float (*pnors)[3];
const int numVerts = dm->getNumVerts(dm);
const int numEdges = dm->getNumEdges(dm);
const int numLoops = dm->getNumLoops(dm);
const int numPolys = dm->getNumPolys(dm);
ldata = dm->getLoopDataLayout(dm);
if (CustomData_has_layer(ldata, CD_NORMAL)) {
lnors = CustomData_get_layer(ldata, CD_NORMAL);
}
else {
lnors = CustomData_add_layer(ldata, CD_NORMAL, CD_CALLOC, NULL, numLoops);
}
/* Compute poly (always needed) and vert normals. */
/* Note we can't use DM_ensure_normals, since it won't keep computed poly nors... */
pdata = dm->getPolyDataLayout(dm);
pnors = CustomData_get_layer(pdata, CD_NORMAL);
if (!pnors) {
pnors = CustomData_add_layer(pdata, CD_NORMAL, CD_CALLOC, NULL, numPolys);
}
Add functions to compute normals (verts, polys and loops ones) for a given shapekey. Title says pretty much everything, we now have BKE and RNA funcs to get vertex, poly and loop normals of a given shapekey. This will be used e.g. in FBX exporter (shapekeys need normal data too). Reviewed By: campbellbarton Differential Revision: https://developer.blender.org/D1510
2015-10-12 20:12:55 +02:00
BKE_mesh_calc_normals_poly(mverts, NULL, numVerts, mloops, mpolys, numLoops, numPolys, pnors,
Split Normals I (1/5): basis for split normals (nearly nothing user-visible here): * Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf). EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit. * Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it (tessellation, rna access, etc.). * Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding this option is now incoherent, will be addressed in a separate commit. Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D365
2014-04-13 12:18:51 +02:00
(dm->dirty & DM_DIRTY_NORMALS) ? false : true);
dm->dirty &= ~DM_DIRTY_NORMALS;
Add Custom Loop Normals. This is the core code for it, tools (datatransfer and modifier) will come in next commits). RNA api is already there, though. See the code for details, but basically, we define, for each 'smooth fan' (which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal), a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store custom normal as two angular factors inside that space. This allows to have custom normals 'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer. Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals, and be converted back into storage format at the end. Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can be rather heavy with high poly meshes. Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
clnor_data = CustomData_get_layer(ldata, CD_CUSTOMLOOPNORMAL);
Split Normals I (1/5): basis for split normals (nearly nothing user-visible here): * Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf). EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit. * Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it (tessellation, rna access, etc.). * Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding this option is now incoherent, will be addressed in a separate commit. Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D365
2014-04-13 12:18:51 +02:00
BKE_mesh_normals_loop_split(mverts, numVerts, medges, numEdges, mloops, lnors, numLoops,
Add Custom Loop Normals. This is the core code for it, tools (datatransfer and modifier) will come in next commits). RNA api is already there, though. See the code for details, but basically, we define, for each 'smooth fan' (which is a set of adjacent loops around a same vertex that are smooth, i.e. have a single same normal), a 'loop normal space' (or lnor space), using auto-computed normal and relevant edges, and store custom normal as two angular factors inside that space. This allows to have custom normals 'following' deformations of the geometry, and to only save two shorts per loop in new clnor CDLayer. Normal manipulation (editing, mixing, interpolating, etc.) shall always happen with plain 3D vectors normals, and be converted back into storage format at the end. Clnor computation has also been threaded (at least for Mesh case, not for BMesh), since the process can be rather heavy with high poly meshes. Also, bumping subversion, and fix mess in 2.70 versioning code.
2015-02-05 14:24:48 +01:00
mpolys, (const float (*)[3])pnors, numPolys,
use_split_normals, split_angle,
r_lnors_spacearr, clnor_data, NULL);
#ifdef DEBUG_CLNORS
if (r_lnors_spacearr) {
int i;
for (i = 0; i < numLoops; i++) {
if (r_lnors_spacearr->lspacearr[i]->ref_alpha != 0.0f) {
LinkNode *loops = r_lnors_spacearr->lspacearr[i]->loops;
printf("Loop %d uses lnor space %p:\n", i, r_lnors_spacearr->lspacearr[i]);
print_v3("\tfinal lnor", lnors[i]);
print_v3("\tauto lnor", r_lnors_spacearr->lspacearr[i]->vec_lnor);
print_v3("\tref_vec", r_lnors_spacearr->lspacearr[i]->vec_ref);
printf("\talpha: %f\n\tbeta: %f\n\tloops: %p\n", r_lnors_spacearr->lspacearr[i]->ref_alpha,
r_lnors_spacearr->lspacearr[i]->ref_beta, r_lnors_spacearr->lspacearr[i]->loops);
printf("\t\t(shared with loops");
while (loops) {
printf(" %d", GET_INT_FROM_POINTER(loops->link));
loops = loops->next;
}
printf(")\n");
}
else {
printf("Loop %d has no lnor space\n", i);
}
}
}
#endif
Split Normals I (1/5): basis for split normals (nearly nothing user-visible here): * Add a new calcLoopNormals function to DerivedMesh struct, and implement it for CDDM and CCGDM (subsurf). EditDerivedBMesh (edit mode DM) only gets a dummy one in this commit. * Add a tessellated version of CD_LOOPNORMAL layer (CD_TESSLOOPNORMAL), with relevant code to handle it (tessellation, rna access, etc.). * Change auto_smooth options of Mesh (angle now in radian internaly, and toggle is now used to enable/disable split normals in DM creation process). Note BI render code is not touched here, hence its behavior regarding this option is now incoherent, will be addressed in a separate commit. Reviewers: campbellbarton CC: brecht Differential Revision: https://developer.blender.org/D365
2014-04-13 12:18:51 +02:00
}
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
void CDDM_calc_normals_tessface(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
float (*face_nors)[3];
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
if (dm->numVertData == 0) return;
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
/* we don't want to overwrite any referenced layers */
cddm->mvert = CustomData_duplicate_referenced_layer(&dm->vertData, CD_MVERT, dm->numVertData);
/* fill in if it exists */
face_nors = CustomData_get_layer(&dm->faceData, CD_NORMAL);
if (!face_nors) {
face_nors = CustomData_add_layer(&dm->faceData, CD_NORMAL, CD_CALLOC, NULL, dm->numTessFaceData);
}
code cleanup: naming - BKE_mesh_*
2012-05-05 21:28:12 +00:00
BKE_mesh_calc_normals_tessface(cddm->mvert, dm->numVertData,
cddm->mface, dm->numTessFaceData, face_nors);
modifier stack: lazy initialize normals many modifiers were calculating normals, when those normals were ignored by the next modifier. now flag normals as dirty and recalculate for modifiers that set use `dependsOnNormals()` callback. Quick test on mesh with 12 modifiers (mostly build type), calculated normals 6 times, now it only runs once - so this will give some speedup too.
2013-05-30 17:36:43 +00:00
cddm->dm.dirty &= ~DM_DIRTY_NORMALS;
added * CDDM_calc_normals * CDDM_calc_normals_tessface these match what we have in trunk - CDDM_calc_normals_mapping() is kept for more comprehensive operatons.
2012-01-06 00:45:07 +00:00
}
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
#if 1
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
/**
* Poly compare with vtargetmap
* Function used by #CDDM_merge_verts.
* The function compares poly_source after applying vtargetmap, with poly_target.
* The two polys are identical if they share the same vertices in the same order, or in reverse order,
* but starting position loopstart may be different.
* The function is called with direct_reverse=1 for same order (i.e. same normal),
* and may be called again with direct_reverse=-1 for reverse order.
* \return 1 if polys are identical, 0 if polys are different.
*/
Cleanup: ws
2015-07-15 12:08:32 +10:00
static int cddm_poly_compare(
MLoop *mloop_array,
MPoly *mpoly_source, MPoly *mpoly_target,
const int *vtargetmap, const int direct_reverse)
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
{
int vert_source, first_vert_source, vert_target;
int i_loop_source;
int i_loop_target, i_loop_target_start, i_loop_target_offset, i_loop_target_adjusted;
bool compare_completed = false;
bool same_loops = false;
MLoop *mloop_source, *mloop_target;
BLI_assert(direct_reverse == 1 || direct_reverse == -1);
i_loop_source = 0;
mloop_source = mloop_array + mpoly_source->loopstart;
vert_source = mloop_source->v;
if (vtargetmap[vert_source] != -1) {
vert_source = vtargetmap[vert_source];
}
else {
/* All source loop vertices should be mapped */
BLI_assert(false);
}
/* Find same vertex within mpoly_target's loops */
mloop_target = mloop_array + mpoly_target->loopstart;
for (i_loop_target = 0; i_loop_target < mpoly_target->totloop; i_loop_target++, mloop_target++) {
if (mloop_target->v == vert_source) {
break;
}
}
/* If same vertex not found, then polys cannot be equal */
if (i_loop_target >= mpoly_target->totloop) {
return false;
}
/* Now mloop_source and m_loop_target have one identical vertex */
/* mloop_source is at position 0, while m_loop_target has advanced to find identical vertex */
/* Go around the loop and check that all vertices match in same order */
/* Skipping source loops when consecutive source vertices are mapped to same target vertex */
i_loop_target_start = i_loop_target;
i_loop_target_offset = 0;
first_vert_source = vert_source;
compare_completed = false;
same_loops = false;
while (!compare_completed) {
vert_target = mloop_target->v;
/* First advance i_loop_source, until it points to different vertex, after mapping applied */
do {
i_loop_source++;
if (i_loop_source == mpoly_source->totloop) {
/* End of loops for source, must match end of loop for target. */
if (i_loop_target_offset == mpoly_target->totloop - 1) {
compare_completed = true;
same_loops = true;
break; /* Polys are identical */
}
else {
compare_completed = true;
same_loops = false;
break; /* Polys are different */
}
}
mloop_source++;
vert_source = mloop_source->v;
if (vtargetmap[vert_source] != -1) {
vert_source = vtargetmap[vert_source];
}
else {
/* All source loop vertices should be mapped */
BLI_assert(false);
}
} while (vert_source == vert_target);
if (compare_completed) {
break;
}
/* Now advance i_loop_target as well */
i_loop_target_offset++;
if (i_loop_target_offset == mpoly_target->totloop) {
/* End of loops for target only, that means no match */
/* except if all remaining source vertices are mapped to first target */
for (; i_loop_source < mpoly_source->totloop; i_loop_source++, mloop_source++) {
vert_source = vtargetmap[mloop_source->v];
if (vert_source != first_vert_source) {
compare_completed = true;
same_loops = false;
break;
}
}
if (!compare_completed) {
same_loops = true;
}
break;
}
/* Adjust i_loop_target for cycling around and for direct/reverse order defined by delta = +1 or -1 */
i_loop_target_adjusted = (i_loop_target_start + direct_reverse * i_loop_target_offset) % mpoly_target->totloop;
if (i_loop_target_adjusted < 0) {
i_loop_target_adjusted += mpoly_target->totloop;
}
mloop_target = mloop_array + mpoly_target->loopstart + i_loop_target_adjusted;
vert_target = mloop_target->v;
if (vert_target != vert_source) {
same_loops = false; /* Polys are different */
break;
}
}
return same_loops;
}
/* Utility stuff for using GHash with polys */
typedef struct PolyKey {
int poly_index; /* index of the MPoly within the derived mesh */
int totloops; /* number of loops in the poly */
unsigned int hash_sum; /* Sum of all vertices indices */
unsigned int hash_xor; /* Xor of all vertices indices */
} PolyKey;
static unsigned int poly_gset_hash_fn(const void *key)
{
const PolyKey *pk = key;
return pk->hash_sum;
}
GHash: use bool for comparison (simplify compare)
2014-09-25 06:15:52 +10:00
static bool poly_gset_compare_fn(const void *k1, const void *k2)
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
{
const PolyKey *pk1 = k1;
const PolyKey *pk2 = k2;
if ((pk1->hash_sum == pk2->hash_sum) &&
(pk1->hash_xor == pk2->hash_xor) &&
(pk1->totloops == pk2->totloops))
{
/* Equality - note that this does not mean equality of polys */
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return false;
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
}
else {
Cleanup: more int->bool.
2014-12-01 17:11:18 +01:00
return true;
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
}
}
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
/**
* Merge Verts
bmesh mirror modifier cleanup * vertex map was a dynamicly realloc'd array when the final size was known, use a fixed array instead. * vertex map was being calculated even when not used. * face tesselation was being called twice. * an unused deform group array was being created.
2011-12-29 09:15:06 +00:00
*
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
* This frees dm, and returns a new one.
*
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
* \param vtargetmap The table that maps vertices to target vertices. a value of -1
bmesh mirror modifier cleanup * vertex map was a dynamicly realloc'd array when the final size was known, use a fixed array instead. * vertex map was being calculated even when not used. * face tesselation was being called twice. * an unused deform group array was being created.
2011-12-29 09:15:06 +00:00
* indicates a vertex is a target, and is to be kept.
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
* This array is aligned with 'dm->numVertData'
bmesh mirror modifier cleanup * vertex map was a dynamicly realloc'd array when the final size was known, use a fixed array instead. * vertex map was being calculated even when not used. * face tesselation was being called twice. * an unused deform group array was being created.
2011-12-29 09:15:06 +00:00
*
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
* \param tot_vtargetmap The number of non '-1' values in vtargetmap. (not the size)
bmesh mirror modifier cleanup * vertex map was a dynamicly realloc'd array when the final size was known, use a fixed array instead. * vertex map was being calculated even when not used. * face tesselation was being called twice. * an unused deform group array was being created.
2011-12-29 09:15:06 +00:00
*
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
* \param merge_mode enum with two modes.
* - #CDDM_MERGE_VERTS_DUMP_IF_MAPPED
* When called by the Mirror Modifier,
* In this mode it skips any faces that have all vertices merged (to avoid creating pairs
* of faces sharing the same set of vertices)
* - #CDDM_MERGE_VERTS_DUMP_IF_EQUAL
* When called by the Array Modifier,
* In this mode, faces where all vertices are merged are double-checked,
* to see whether all target vertices actually make up a poly already.
* Indeed it could be that all of a poly's vertices are merged,
* but merged to vertices that do not make up a single poly,
* in which case the original poly should not be dumped.
* Actually this later behavior could apply to the Mirror Modifier as well, but the additional checks are
* costly and not necessary in the case of mirror, because each vertex is only merged to its own mirror.
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
*
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
* \note #CDDM_recalc_tessellation has to run on the returned DM if you want to access tessfaces.
pre-merge commit
2011-02-15 01:16:32 +00:00
*/
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
DerivedMesh *CDDM_merge_verts(DerivedMesh *dm, const int *vtargetmap, const int tot_vtargetmap, const int merge_mode)
pre-merge commit
2011-02-15 01:16:32 +00:00
{
CDDM_merge_verts() was building an index array for all loops and not using it. also use malloc over calloc since the values are filled in right after.
2013-01-19 02:01:18 +00:00
// #define USE_LOOPS
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
pre-merge commit
2011-02-15 01:16:32 +00:00
CDDerivedMesh *cddm2 = NULL;
fix own bug with uninitialized arrays in subdivide (from recent BLI_array.h update) also quiet warning.
2013-01-20 08:05:23 +00:00
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
const int totvert = dm->numVertData;
const int totedge = dm->numEdgeData;
const int totloop = dm->numLoopData;
const int totpoly = dm->numPolyData;
const int totvert_final = totvert - tot_vtargetmap;
MVert *mv, *mvert = MEM_mallocN(sizeof(*mvert) * totvert_final, __func__);
int *oldv = MEM_mallocN(sizeof(*oldv) * totvert_final, __func__);
int *newv = MEM_mallocN(sizeof(*newv) * totvert, __func__);
STACK_DECLARE(mvert);
STACK_DECLARE(oldv);
MEdge *med, *medge = MEM_mallocN(sizeof(*medge) * totedge, __func__);
int *olde = MEM_mallocN(sizeof(*olde) * totedge, __func__);
int *newe = MEM_mallocN(sizeof(*newe) * totedge, __func__);
STACK_DECLARE(medge);
STACK_DECLARE(olde);
MLoop *ml, *mloop = MEM_mallocN(sizeof(*mloop) * totloop, __func__);
int *oldl = MEM_mallocN(sizeof(*oldl) * totloop, __func__);
fix own bug with uninitialized arrays in subdivide (from recent BLI_array.h update) also quiet warning.
2013-01-20 08:05:23 +00:00
#ifdef USE_LOOPS
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
int newl = MEM_mallocN(sizeof(*newl) * totloop, __func__);
fix own bug with uninitialized arrays in subdivide (from recent BLI_array.h update) also quiet warning.
2013-01-20 08:05:23 +00:00
#endif
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
STACK_DECLARE(mloop);
STACK_DECLARE(oldl);
MPoly *mp, *mpoly = MEM_mallocN(sizeof(*medge) * totpoly, __func__);
int *oldp = MEM_mallocN(sizeof(*oldp) * totpoly, __func__);
STACK_DECLARE(mpoly);
STACK_DECLARE(oldp);
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
EdgeHash *ehash = BLI_edgehash_new_ex(__func__, totedge);
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
int i, j, c;
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
PolyKey *poly_keys;
GSet *poly_gset = NULL;
BLI_stackdefines Bounds check the stack while debugging, also add STACK_PEEK
2014-06-29 05:06:22 +10:00
STACK_INIT(oldv, totvert_final);
STACK_INIT(olde, totedge);
STACK_INIT(oldl, totloop);
STACK_INIT(oldp, totpoly);
STACK_INIT(mvert, totvert_final);
STACK_INIT(medge, totedge);
STACK_INIT(mloop, totloop);
STACK_INIT(mpoly, totpoly);
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
fix own error in recent smoothview cleanup, also correct some cross references in bmesh docs.
2012-08-17 14:43:20 +00:00
/* fill newl with destination vertex indices */
pre-merge commit
2011-02-15 01:16:32 +00:00
mv = cddm->mvert;
c = 0;
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
for (i = 0; i < totvert; i++, mv++) {
pre-merge commit
2011-02-15 01:16:32 +00:00
if (vtargetmap[i] == -1) {
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
STACK_PUSH(oldv, i);
STACK_PUSH(mvert, *mv);
pre-merge commit
2011-02-15 01:16:32 +00:00
newv[i] = c++;
}
CDDM_merge_verts() was building an index array for all loops and not using it. also use malloc over calloc since the values are filled in right after.
2013-01-19 02:01:18 +00:00
else {
/* dummy value */
newv[i] = 0;
}
pre-merge commit
2011-02-15 01:16:32 +00:00
}
fix own error in recent smoothview cleanup, also correct some cross references in bmesh docs.
2012-08-17 14:43:20 +00:00
/* now link target vertices to destination indices */
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
for (i = 0; i < totvert; i++) {
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
if (vtargetmap[i] != -1) {
newv[i] = newv[vtargetmap[i]];
}
}
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
/* Don't remap vertices in cddm->mloop, because we need to know the original
style cleanup
2012-11-11 11:00:55 +00:00
* indices in order to skip faces with all vertices merged.
* The "update loop indices..." section further down remaps vertices in mloop.
*/
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
fix own error in recent smoothview cleanup, also correct some cross references in bmesh docs.
2012-08-17 14:43:20 +00:00
/* now go through and fix edges and faces */
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
med = cddm->medge;
pre-merge commit
2011-02-15 01:16:32 +00:00
c = 0;
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
for (i = 0; i < totedge; i++, med++) {
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
const unsigned int v1 = (vtargetmap[med->v1] != -1) ? vtargetmap[med->v1] : med->v1;
const unsigned int v2 = (vtargetmap[med->v2] != -1) ? vtargetmap[med->v2] : med->v2;
if (LIKELY(v1 != v2)) {
Use BKE_edgehash_ensure_p where possible
2015-04-07 10:53:58 +10:00
void **val_p;
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
Use BKE_edgehash_ensure_p where possible
2015-04-07 10:53:58 +10:00
if (BLI_edgehash_ensure_p(ehash, v1, v2, &val_p)) {
newe[i] = GET_INT_FROM_POINTER(*val_p);
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
}
else {
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
STACK_PUSH(olde, i);
STACK_PUSH(medge, *med);
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
newe[i] = c;
Use BKE_edgehash_ensure_p where possible
2015-04-07 10:53:58 +10:00
*val_p = SET_INT_IN_POINTER(c);
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
c++;
}
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
}
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
else {
newe[i] = -1;
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
}
pre-merge commit
2011-02-15 01:16:32 +00:00
}
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
if (merge_mode == CDDM_MERGE_VERTS_DUMP_IF_EQUAL) {
/* In this mode, we need to determine, whenever a poly' vertices are all mapped */
/* if the targets already make up a poly, in which case the new poly is dropped */
/* This poly equality check is rather complex. We use a BLI_ghash to speed it up with a first level check */
PolyKey *mpgh;
poly_keys = MEM_mallocN(sizeof(PolyKey) * totpoly, __func__);
poly_gset = BLI_gset_new_ex(poly_gset_hash_fn, poly_gset_compare_fn, __func__, totpoly);
/* Duplicates allowed because our compare function is not pure equality */
BLI_gset_flag_set(poly_gset, GHASH_FLAG_ALLOW_DUPES);
mp = cddm->mpoly;
mpgh = poly_keys;
for (i = 0; i < totpoly; i++, mp++, mpgh++) {
mpgh->poly_index = i;
mpgh->totloops = mp->totloop;
ml = cddm->mloop + mp->loopstart;
mpgh->hash_sum = mpgh->hash_xor = 0;
for (j = 0; j < mp->totloop; j++, ml++) {
mpgh->hash_sum += ml->v;
mpgh->hash_xor ^= ml->v;
}
BLI_gset_insert(poly_gset, mpgh);
}
if (cddm->pmap) {
MEM_freeN(cddm->pmap);
MEM_freeN(cddm->pmap_mem);
}
/* Can we optimise by reusing an old pmap ? How do we know an old pmap is stale ? */
/* When called by MOD_array.c, the cddm has just been created, so it has no valid pmap. */
BKE_mesh_vert_poly_map_create(&cddm->pmap, &cddm->pmap_mem,
cddm->mpoly, cddm->mloop,
totvert, totpoly, totloop);
} /* done preparing for fast poly compare */
pre-merge commit
2011-02-15 01:16:32 +00:00
mp = cddm->mpoly;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < totpoly; i++, mp++) {
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
MPoly *mp_new;
pre-merge commit
2011-02-15 01:16:32 +00:00
ml = cddm->mloop + mp->loopstart;
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
/* check faces with all vertices merged */
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
{
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
bool all_vertices_merged = true;
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
for (j = 0; j < mp->totloop; j++, ml++) {
if (vtargetmap[ml->v] == -1) {
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
all_vertices_merged = false;
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
break;
}
}
style cleanup
2012-11-11 11:00:55 +00:00
if (UNLIKELY(all_vertices_merged)) {
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
if (merge_mode == CDDM_MERGE_VERTS_DUMP_IF_MAPPED) {
/* In this mode, all vertices merged is enough to dump face */
continue;
}
else if (merge_mode == CDDM_MERGE_VERTS_DUMP_IF_EQUAL) {
/* Additional condition for face dump: target vertices must make up an identical face */
/* The test has 2 steps: (1) first step is fast ghash lookup, but not failproof */
/* (2) second step is thorough but more costly poly compare */
int i_poly, v_target, v_prev;
bool found = false;
PolyKey pkey;
/* Use poly_gset for fast (although not 100% certain) identification of same poly */
/* First, make up a poly_summary structure */
ml = cddm->mloop + mp->loopstart;
pkey.hash_sum = pkey.hash_xor = 0;
pkey.totloops = 0;
v_prev = vtargetmap[(ml + mp->totloop -1)->v]; /* since it loops around, the prev of first is the last */
for (j = 0; j < mp->totloop; j++, ml++) {
v_target = vtargetmap[ml->v]; /* Cannot be -1, they are all mapped */
if (v_target == v_prev) {
/* consecutive vertices in loop map to the same target: discard */
/* but what about last to first ? */
continue;
}
pkey.hash_sum += v_target;
pkey.hash_xor ^= v_target;
pkey.totloops++;
v_prev = v_target;
}
if (BLI_gset_haskey(poly_gset, &pkey)) {
/* There might be a poly that matches this one.
* We could just leave it there and say there is, and do a "continue".
* ... but we are checking whether there is an exact poly match.
* It's not so costly in terms of CPU since it's very rare, just a lot of complex code.
*/
/* Consider current loop again */
ml = cddm->mloop + mp->loopstart;
/* Consider the target of the loop's first vert */
v_target = vtargetmap[ml->v];
/* Now see if v_target belongs to a poly that shares all vertices with source poly,
* in same order, or reverse order */
for (i_poly = 0; i_poly < cddm->pmap[v_target].count; i_poly++) {
MPoly *target_poly = cddm->mpoly + *(cddm->pmap[v_target].indices + i_poly);
if (cddm_poly_compare(cddm->mloop, mp, target_poly, vtargetmap, +1) ||
cddm_poly_compare(cddm->mloop, mp, target_poly, vtargetmap, -1))
{
found = true;
break;
}
}
if (found) {
/* Current poly's vertices are mapped to a poly that is strictly identical */
/* Current poly is dumped */
continue;
}
}
}
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
}
}
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
/* Here either the poly's vertices were not all merged
* or they were all merged, but targets do not make up an identical poly,
* the poly is retained.
*/
Fix #32398: Mirror modifier with "Merge" enabled producing pairs of faces sharing the same set of vertices. Modified the CDDM_merge_verts function (currently only used by the Mirror modifier) to skip faces using all merged vertices.
2012-11-11 04:53:20 +00:00
ml = cddm->mloop + mp->loopstart;
pre-merge commit
2011-02-15 01:16:32 +00:00
c = 0;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (j = 0; j < mp->totloop; j++, ml++) {
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
unsigned int v1, v2;
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
med = cddm->medge + ml->e;
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
v1 = (vtargetmap[med->v1] != -1) ? vtargetmap[med->v1] : med->v1;
v2 = (vtargetmap[med->v2] != -1) ? vtargetmap[med->v2] : med->v2;
if (LIKELY(v1 != v2)) {
CDDM_merge_verts() was building an index array for all loops and not using it. also use malloc over calloc since the values are filled in right after.
2013-01-19 02:01:18 +00:00
#ifdef USE_LOOPS
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
newl[j + mp->loopstart] = STACK_SIZE(mloop);
CDDM_merge_verts() was building an index array for all loops and not using it. also use malloc over calloc since the values are filled in right after.
2013-01-19 02:01:18 +00:00
#endif
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
STACK_PUSH(oldl, j + mp->loopstart);
STACK_PUSH(mloop, *ml);
pre-merge commit
2011-02-15 01:16:32 +00:00
c++;
}
}
minor changes for mirror modifier, bigger changes coming.
2012-01-03 09:37:57 +00:00
if (UNLIKELY(c == 0)) {
pre-merge commit
2011-02-15 01:16:32 +00:00
continue;
minor changes for mirror modifier, bigger changes coming.
2012-01-03 09:37:57 +00:00
}
Fix for 2-sided faces in array modifier
2014-10-03 13:59:06 +02:00
else if (UNLIKELY(c < 3)) {
STACK_DISCARD(oldl, c);
STACK_DISCARD(mloop, c);
continue;
}
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
mp_new = STACK_PUSH_RET_PTR(mpoly);
*mp_new = *mp;
mp_new->totloop = c;
Fix for 2-sided faces in array modifier
2014-10-03 13:59:06 +02:00
BLI_assert(mp_new->totloop >= 3);
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
mp_new->loopstart = STACK_SIZE(mloop) - c;
pre-merge commit
2011-02-15 01:16:32 +00:00
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
STACK_PUSH(oldp, i);
Rewritten Array Modifier D443 Patch by PatB with own edits - replace BMesh with CDDM functions. - faster remove-vertex merging. - extend CDDM_merge_verts to be more flexible.
2014-08-12 13:52:17 +10:00
} /* end of the loop that tests polys */
if (poly_gset) {
// printf("hash quality %.6f\n", BLI_gset_calc_quality(poly_gset));
BLI_gset_free(poly_gset, NULL);
MEM_freeN(poly_keys);
pre-merge commit
2011-02-15 01:16:32 +00:00
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
/*create new cddm*/
Cleanup: style Also 'com' as abbreviation for center-of-mass is a bit confusing, rename to 'center'.
2015-07-20 05:19:47 +10:00
cddm2 = (CDDerivedMesh *)CDDM_from_template(
(DerivedMesh *)cddm, STACK_SIZE(mvert), STACK_SIZE(medge), 0, STACK_SIZE(mloop), STACK_SIZE(mpoly));
pre-merge commit
2011-02-15 01:16:32 +00:00
/*update edge indices and copy customdata*/
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
med = medge;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < cddm2->dm.numEdgeData; i++, med++) {
minor speedup to CDDM_merge_verts (called by mirror) * was doing 2 edge hash lookups, where only 1 was needed. * was checking MLoop verts and edges if they were -1, when they are never set to -1
2011-12-29 09:41:31 +00:00
if (newv[med->v1] != -1)
med->v1 = newv[med->v1];
if (newv[med->v2] != -1)
med->v2 = newv[med->v2];
pre-merge commit
2011-02-15 01:16:32 +00:00
CustomData_copy_data(&dm->edgeData, &cddm2->dm.edgeData, olde[i], i, 1);
}
/*update loop indices and copy customdata*/
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
ml = mloop;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < cddm2->dm.numLoopData; i++, ml++) {
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
if (newe[ml->e] != -1)
ml->e = newe[ml->e];
if (newv[ml->v] != -1)
ml->v = newv[ml->v];
pre-merge commit
2011-02-15 01:16:32 +00:00
CustomData_copy_data(&dm->loopData, &cddm2->dm.loopData, oldl[i], i, 1);
}
style cleanup: trailing tabs & expand some non prefix tabs into spaces.
2012-10-21 05:46:41 +00:00
/*copy vertex customdata*/
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
mv = mvert;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < cddm2->dm.numVertData; i++, mv++) {
pre-merge commit
2011-02-15 01:16:32 +00:00
CustomData_copy_data(&dm->vertData, &cddm2->dm.vertData, oldv[i], i, 1);
}
/*copy poly customdata*/
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
mp = mpoly;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < cddm2->dm.numPolyData; i++, mp++) {
pre-merge commit
2011-02-15 01:16:32 +00:00
CustomData_copy_data(&dm->polyData, &cddm2->dm.polyData, oldp[i], i, 1);
}
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
/*copy over data. CustomData_add_layer can do this, need to look it up.*/
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
memcpy(cddm2->mvert, mvert, sizeof(MVert) * STACK_SIZE(mvert));
memcpy(cddm2->medge, medge, sizeof(MEdge) * STACK_SIZE(medge));
memcpy(cddm2->mloop, mloop, sizeof(MLoop) * STACK_SIZE(mloop));
memcpy(cddm2->mpoly, mpoly, sizeof(MPoly) * STACK_SIZE(mpoly));
MEM_freeN(mvert);
MEM_freeN(medge);
MEM_freeN(mloop);
MEM_freeN(mpoly);
MEM_freeN(newv);
MEM_freeN(newe);
CDDM_merge_verts() was building an index array for all loops and not using it. also use malloc over calloc since the values are filled in right after.
2013-01-19 02:01:18 +00:00
#ifdef USE_LOOPS
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
MEM_freeN(newl);
CDDM_merge_verts() was building an index array for all loops and not using it. also use malloc over calloc since the values are filled in right after.
2013-01-19 02:01:18 +00:00
#endif
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
MEM_freeN(oldv);
MEM_freeN(olde);
MEM_freeN(oldl);
Cleanup
2014-09-27 00:57:54 +10:00
MEM_freeN(oldp);
optimize mirror merging, remove array reallocation, replace with fixed size arrays.
2013-05-27 20:11:12 +00:00
BLI_edgehash_free(ehash, NULL);
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
/*free old derivedmesh*/
pre-merge commit
2011-02-15 01:16:32 +00:00
dm->needsFree = 1;
dm->release(dm);
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return (DerivedMesh *)cddm2;
pre-merge commit
2011-02-15 01:16:32 +00:00
}
#endif
rename * CDDM_calc_edges --> CDDM_calc_edges_tessface * CDDM_calc_edges_poly --> CDDM_calc_edges
2012-01-06 02:59:28 +00:00
void CDDM_calc_edges_tessface(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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)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
CustomData edgeData;
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
EdgeSetIterator *ehi;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
MFace *mf = cddm->mface;
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
MEdge *med;
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
EdgeSet *eh;
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
int i, *index, numEdges, numFaces = dm->numTessFaceData;
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
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
eh = BLI_edgeset_new_ex(__func__, BLI_EDGEHASH_SIZE_GUESS_FROM_POLYS(numFaces));
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
for (i = 0; i < numFaces; i++, mf++) {
GSet, GHash: Add BLI_gset_add, since its common to add members to a set also rename BLI_edgeset_reinsert -> BLI_edgeset_add, in this case its the same.
2014-05-29 14:00:11 +10:00
BLI_edgeset_add(eh, mf->v1, mf->v2);
BLI_edgeset_add(eh, mf->v2, mf->v3);
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
if (mf->v4) {
GSet, GHash: Add BLI_gset_add, since its common to add members to a set also rename BLI_edgeset_reinsert -> BLI_edgeset_add, in this case its the same.
2014-05-29 14:00:11 +10:00
BLI_edgeset_add(eh, mf->v3, mf->v4);
BLI_edgeset_add(eh, mf->v4, mf->v1);
style cleanup: follow style guide for formatting of if/for/while loops, and else if's
2012-03-24 06:18:31 +00:00
}
else {
GSet, GHash: Add BLI_gset_add, since its common to add members to a set also rename BLI_edgeset_reinsert -> BLI_edgeset_add, in this case its the same.
2014-05-29 14:00:11 +10:00
BLI_edgeset_add(eh, mf->v3, mf->v1);
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
}
}
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
numEdges = BLI_edgeset_size(eh);
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
/* write new edges into a temporary CustomData */
fix for asserts caused by own recent commits to use customdata typemap.
2012-10-31 15:17:35 +00:00
CustomData_reset(&edgeData);
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
CustomData_add_layer(&edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
CustomData_add_layer(&edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
Bugfix: added ORIGINDEX layer in CDDM_calc_edges, this could crash some modifier combinations.
2006-11-23 17:35:45 +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
med = CustomData_get_layer(&edgeData, CD_MEDGE);
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
index = CustomData_get_layer(&edgeData, CD_ORIGINDEX);
code cleanup: - style - multi-line ifs move braces onto new lines. - iterators - convert some to macros, other split up and move brace.
2012-05-20 19:49:27 +00:00
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
for (ehi = BLI_edgesetIterator_new(eh), i = 0;
BLI_edgesetIterator_isDone(ehi) == false;
BLI_edgesetIterator_step(ehi), i++, med++, index++)
code cleanup: - style - multi-line ifs move braces onto new lines. - iterators - convert some to macros, other split up and move brace.
2012-05-20 19:49:27 +00:00
{
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
BLI_edgesetIterator_getKey(ehi, &med->v1, &med->v2);
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
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
med->flag = ME_EDGEDRAW | ME_EDGERENDER;
Bugfix: added ORIGINDEX layer in CDDM_calc_edges, this could crash some modifier combinations.
2006-11-23 17:35:45 +00:00
*index = ORIGINDEX_NONE;
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
}
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
BLI_edgesetIterator_free(ehi);
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
/* free old CustomData and assign new one */
RNA * Mesh.add_geometry, Mesh.update and make indices editable. This is without checking if they are valid still, no time now to implement this. * Also fix warnings in rna_ui.c, and a bug in CDDM_calc_edges. Example code: co = [0.0, 0.0, 0.0] + [1.0, 0.0, 0.0] + [0.0, 1.0, 0.0] + [1.0, 1.0, 0.0] faces = [0, 1, 2, 0] + [1, 3, 2, 0] mesh.add_geometry(4, 0, 2) mesh.verts.foreach_set("co", co) mesh.faces.foreach_set("verts", faces) mesh.update()
2009-07-01 12:19:00 +00:00
CustomData_free(&dm->edgeData, dm->numEdgeData);
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
dm->edgeData = edgeData;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
dm->numEdgeData = numEdges;
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
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
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
BLI_edgeset_free(eh);
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
}
rename * CDDM_calc_edges --> CDDM_calc_edges_tessface * CDDM_calc_edges_poly --> CDDM_calc_edges
2012-01-06 02:59:28 +00:00
/* warning, this uses existing edges but CDDM_calc_edges_tessface() doesn't */
void CDDM_calc_edges(DerivedMesh *dm)
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
CustomData edgeData;
EdgeHashIterator *ehi;
MPoly *mp = cddm->mpoly;
MLoop *ml;
Triangulate modifier Useful for bump map baking where a consistent triangulation should be enforced when baking/exporting/importing, to avoid artifacts caused by a different triangulation of the mesh by that which was used for baking by internal/external tools. documentation is here http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65/More_Features Will probably add some pictures too to demonstrate the issue that is solved more clearly. Currently using the skin modifier icon, will soon change that. Review by Brecht, thanks!
2012-11-19 20:40:08 +00:00
MEdge *med, *origmed;
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
EdgeHash *eh;
unsigned int eh_reserve;
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
int v1, v2;
Code cleanup: use 'const' for arrays (blenkernel)
2014-04-27 00:20:13 +10:00
const int *eindex;
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
int i, j, *index;
const int numFaces = dm->numPolyData;
const int numLoops = dm->numLoopData;
int numEdges = dm->numEdgeData;
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
eindex = DM_get_edge_data_layer(dm, CD_ORIGINDEX);
med = cddm->medge;
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
eh_reserve = max_ii(med ? numEdges : 0, BLI_EDGEHASH_SIZE_GUESS_FROM_LOOPS(numLoops));
eh = BLI_edgehash_new_ex(__func__, eh_reserve);
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
if (med) {
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (i = 0; i < numEdges; i++, med++) {
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
BLI_edgehash_insert(eh, med->v1, med->v2, SET_INT_IN_POINTER(i + 1));
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
}
}
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
for (i = 0; i < numFaces; i++, mp++) {
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
ml = cddm->mloop + mp->loopstart;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (j = 0; j < mp->totloop; j++, ml++) {
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
v1 = ml->v;
macro for getting next/previous MPoly loops
2011-12-28 07:10:27 +00:00
v2 = ME_POLY_LOOP_NEXT(cddm->mloop, mp, j)->v;
DerivedMesh: replace edgehash with edgeset
2014-04-08 14:44:46 +10:00
BLI_edgehash_reinsert(eh, v1, v2, NULL);
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
}
}
numEdges = BLI_edgehash_size(eh);
/* write new edges into a temporary CustomData */
fix for asserts caused by own recent commits to use customdata typemap.
2012-10-31 15:17:35 +00:00
CustomData_reset(&edgeData);
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
CustomData_add_layer(&edgeData, CD_MEDGE, CD_CALLOC, NULL, numEdges);
CustomData_add_layer(&edgeData, CD_ORIGINDEX, CD_CALLOC, NULL, numEdges);
Triangulate modifier Useful for bump map baking where a consistent triangulation should be enforced when baking/exporting/importing, to avoid artifacts caused by a different triangulation of the mesh by that which was used for baking by internal/external tools. documentation is here http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65/More_Features Will probably add some pictures too to demonstrate the issue that is solved more clearly. Currently using the skin modifier icon, will soon change that. Review by Brecht, thanks!
2012-11-19 20:40:08 +00:00
origmed = cddm->medge;
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
med = CustomData_get_layer(&edgeData, CD_MEDGE);
index = CustomData_get_layer(&edgeData, CD_ORIGINDEX);
code cleanup: - style - multi-line ifs move braces onto new lines. - iterators - convert some to macros, other split up and move brace.
2012-05-20 19:49:27 +00:00
for (ehi = BLI_edgehashIterator_new(eh), i = 0;
Code cleanup: remove TRUE/FALSE & WITH_BOOL_COMPAT define
2014-04-01 11:34:00 +11:00
BLI_edgehashIterator_isDone(ehi) == false;
code cleanup: - style - multi-line ifs move braces onto new lines. - iterators - convert some to macros, other split up and move brace.
2012-05-20 19:49:27 +00:00
BLI_edgehashIterator_step(ehi), ++i, ++med, ++index)
{
un-inline edgehash functions, BLI_edgehash_insert was far too big to inline. and have edge hash use unsigned ints since edge verts are unsigned ints for MEdge's
2011-12-28 10:06:10 +00:00
BLI_edgehashIterator_getKey(ehi, &med->v1, &med->v2);
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
j = GET_INT_FROM_POINTER(BLI_edgehashIterator_getValue(ehi));
fix for changes in own recent commit: selected linked in face mode was crashing. (needs bmesh operator flags) also some style edits, remove unused includes and change triangulate modifiers use_beauty to a flag.
2012-11-19 23:52:24 +00:00
if (j == 0) {
Triangulate modifier Useful for bump map baking where a consistent triangulation should be enforced when baking/exporting/importing, to avoid artifacts caused by a different triangulation of the mesh by that which was used for baking by internal/external tools. documentation is here http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.65/More_Features Will probably add some pictures too to demonstrate the issue that is solved more clearly. Currently using the skin modifier icon, will soon change that. Review by Brecht, thanks!
2012-11-19 20:40:08 +00:00
med->flag = ME_EDGEDRAW | ME_EDGERENDER;
*index = ORIGINDEX_NONE;
}
else {
med->flag = ME_EDGEDRAW | ME_EDGERENDER | origmed[j - 1].flag;
*index = eindex[j - 1];
}
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
BLI_edgehashIterator_setValue(ehi, SET_INT_IN_POINTER(i));
}
BLI_edgehashIterator_free(ehi);
/* free old CustomData and assign new one */
CustomData_free(&dm->edgeData, dm->numEdgeData);
dm->edgeData = edgeData;
dm->numEdgeData = numEdges;
cddm->medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
mp = cddm->mpoly;
when the size of an edgehash is known or can be guessed, pass in the argument to reserve the size.
2013-08-24 13:47:57 +00:00
for (i = 0; i < numFaces; i++, mp++) {
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
ml = cddm->mloop + mp->loopstart;
Style cleanup: spaces around operator
2012-05-01 12:51:17 +00:00
for (j = 0; j < mp->totloop; j++, ml++) {
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
v1 = ml->v;
macro for getting next/previous MPoly loops
2011-12-28 07:10:27 +00:00
v2 = ME_POLY_LOOP_NEXT(cddm->mloop, mp, j)->v;
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
ml->e = GET_INT_FROM_POINTER(BLI_edgehash_lookup(eh, v1, v2));
}
}
BLI_edgehash_free(eh, NULL);
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
void CDDM_lower_num_verts(DerivedMesh *dm, int numVerts)
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 CDDM_lower_num_loops(), for completeness (currently unused).
2013-11-04 12:01:46 +00:00
BLI_assert(numVerts >= 0);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
if (numVerts < dm->numVertData)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CustomData_free_elem(&dm->vertData, numVerts, dm->numVertData - numVerts);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
dm->numVertData = numVerts;
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
void CDDM_lower_num_edges(DerivedMesh *dm, int numEdges)
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 CDDM_lower_num_loops(), for completeness (currently unused).
2013-11-04 12:01:46 +00:00
BLI_assert(numEdges >= 0);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
if (numEdges < dm->numEdgeData)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CustomData_free_elem(&dm->edgeData, numEdges, dm->numEdgeData - numEdges);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
dm->numEdgeData = numEdges;
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
}
remesh now working for bmesh
2011-12-31 12:58:03 +00:00
void CDDM_lower_num_tessfaces(DerivedMesh *dm, int numTessFaces)
{
add CDDM_lower_num_loops(), for completeness (currently unused).
2013-11-04 12:01:46 +00:00
BLI_assert(numTessFaces >= 0);
remesh now working for bmesh
2011-12-31 12:58:03 +00:00
if (numTessFaces < dm->numTessFaceData)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CustomData_free_elem(&dm->faceData, numTessFaces, dm->numTessFaceData - numTessFaces);
remesh now working for bmesh
2011-12-31 12:58:03 +00:00
dm->numTessFaceData = numTessFaces;
}
add CDDM_lower_num_loops(), for completeness (currently unused).
2013-11-04 12:01:46 +00:00
void CDDM_lower_num_loops(DerivedMesh *dm, int numLoops)
{
BLI_assert(numLoops >= 0);
if (numLoops < dm->numLoopData)
CustomData_free_elem(&dm->loopData, numLoops, dm->numLoopData - numLoops);
dm->numLoopData = numLoops;
}
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
void CDDM_lower_num_polys(DerivedMesh *dm, 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
{
add CDDM_lower_num_loops(), for completeness (currently unused).
2013-11-04 12:01:46 +00:00
BLI_assert(numPolys >= 0);
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
if (numPolys < dm->numPolyData)
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CustomData_free_elem(&dm->polyData, numPolys, dm->numPolyData - numPolys);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 04:28:02 +00:00
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
dm->numPolyData = 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
}
Code cleanup for BMesh CDDM access functions, no functional changes. Renamed CDDM_get_face() to CDDM_get_poly() to match array access functions. Added function definitions for CDDM_get_loop() and CDDM_get_poly().
2012-02-07 01:13:04 +00:00
/* mesh element access functions */
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
MVert *CDDM_get_vert(DerivedMesh *dm, int index)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return &((CDDerivedMesh *)dm)->mvert[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
}
MEdge *CDDM_get_edge(DerivedMesh *dm, int index)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return &((CDDerivedMesh *)dm)->medge[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
}
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
MFace *CDDM_get_tessface(DerivedMesh *dm, int index)
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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return &((CDDerivedMesh *)dm)->mface[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
}
Code cleanup for BMesh CDDM access functions, no functional changes. Renamed CDDM_get_face() to CDDM_get_poly() to match array access functions. Added function definitions for CDDM_get_loop() and CDDM_get_poly().
2012-02-07 01:13:04 +00:00
MLoop *CDDM_get_loop(DerivedMesh *dm, int index)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return &((CDDerivedMesh *)dm)->mloop[index];
Code cleanup for BMesh CDDM access functions, no functional changes. Renamed CDDM_get_face() to CDDM_get_poly() to match array access functions. Added function definitions for CDDM_get_loop() and CDDM_get_poly().
2012-02-07 01:13:04 +00:00
}
MPoly *CDDM_get_poly(DerivedMesh *dm, int index)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return &((CDDerivedMesh *)dm)->mpoly[index];
Code cleanup for BMesh CDDM access functions, no functional changes. Renamed CDDM_get_face() to CDDM_get_poly() to match array access functions. Added function definitions for CDDM_get_loop() and CDDM_get_poly().
2012-02-07 01:13:04 +00:00
}
/* array access functions */
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
MVert *CDDM_get_verts(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return ((CDDerivedMesh *)dm)->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
}
MEdge *CDDM_get_edges(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return ((CDDerivedMesh *)dm)->medge;
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
MFace *CDDM_get_tessfaces(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
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return ((CDDerivedMesh *)dm)->mface;
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
}
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
MLoop *CDDM_get_loops(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return ((CDDerivedMesh *)dm)->mloop;
=bmesh= Mirror modifier no longer uses bmesh, but is now 100% CDDM. This is faster; the sluggishness was driving me crazy. Still need to deal with UVs, but that shouldn't be hard.
2011-02-27 07:49:36 +00:00
}
merge with/from trunk at r35190
2011-02-27 06:19:40 +00:00
MPoly *CDDM_get_polys(DerivedMesh *dm)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
return ((CDDerivedMesh *)dm)->mpoly;
merge with/from trunk at r35190
2011-02-27 06:19:40 +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
void CDDM_tessfaces_to_faces(DerivedMesh *dm)
{
Fix #31172: applying boolean removes uv maps The issue was caused by CDDM_tessfaces_to_faces not dealing with CD layers. There was already function BKE_mesh_convert_mfaces_to_mpolys which converted mfaces to mpolys with converting all CD layers. Made it a bit more general so it might work with given arrays of faces/polys and re-used it from CDDM module. Checked with UV and sculpt data from Blender 2.61 and it loaded nice, so hopefully there's no regressions in loading older files.
2012-06-04 12:10:38 +00:00
/* converts mfaces to mpolys/mloops */
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
CDDM_calc_edges_tessface was being called twice for boolean and explide modifiers, now leave it up to the caller to run.
2012-03-20 00:59:51 +00:00
Cleanup: ws
2015-07-15 12:08:32 +10:00
BKE_mesh_convert_mfaces_to_mpolys_ex(
NULL, &cddm->dm.faceData, &cddm->dm.loopData, &cddm->dm.polyData,
cddm->dm.numEdgeData, cddm->dm.numTessFaceData,
cddm->dm.numLoopData, cddm->dm.numPolyData,
cddm->medge, cddm->mface,
&cddm->dm.numLoopData, &cddm->dm.numPolyData,
&cddm->mloop, &cddm->mpoly);
(NOTE: DO NOT TEST) Start of planned DerivedMesh refactoring. The mface interfaces in DerivedMesh have been renamed to reflect their new status as tesselated face interfaces (rather then the primary ones, which are now stored in mpolys). short review: mpolys store "primary" face data, while mfaces store the tesselated form of the mesh (generally as triangles). mpolys are defined by mloops, and each mpoly defines a range of loops it "owns" in the main mloop array. I've also added basic read-only face iterators, which are implemented for CDDM, ccgsubsurf, and the bmeditmesh derivedmesh. Since faces are now variable-length things, trying to implement the same interface as mfaces would not have worked well (especially since faces are stored as an mpoly + a range of mloops). I figure first we can evaluate these simple read-only face iterators, then decide if a) we like using iterators in DerivedMesh, b) how much of it should use them, and c) if we want write-capable iterators. I plan to write official docs on this design after I get it more stable; I'm committing now because there's a rather lot of changes, and I might do a merge soon.
2009-06-10 10:06:25 +00:00
}
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
void CDDM_set_mvert(DerivedMesh *dm, MVert *mvert)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
=bmesh= fixed edge split modifier, and a bug in knifetool reported by letterrip. also brought back beautify-fill.
2011-04-22 23:37:58 +00:00
if (!CustomData_has_layer(&dm->vertData, CD_MVERT))
CustomData_add_layer(&dm->vertData, CD_MVERT, CD_ASSIGN, mvert, dm->numVertData);
Cleanup: ws
2015-07-15 12:08:32 +10:00
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
cddm->mvert = mvert;
}
void CDDM_set_medge(DerivedMesh *dm, MEdge *medge)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Merge with trunk/2.5 at r25563 Most likely will not compile for others, I'd appreciate any build errors and missing files reports (I can never seem to get everything committed and all the build systems working without help). Porting over the sculpt/multires tools was a breeze, thanks goes to brecht for a design that didn't exclude ngons and was easy to port. Note that I've not tested externally-backed multires file support yet. Also, I still need to write version patch code for some cases. Some notes: * Like trunk, topological changes don't update multires right, so e.g. subdivide will duplicate multires data on the new faces, instead of subdividing it. * If you set the debug value (ctrl-alt-d) to 1 it'll turn on my experiments in speeding up sculpting on higher-res multires meshes (but note it makes partial redraw not completely accurate). * There's a bug where you have to go through editmode to get out of sculpt mode, not sure if I inherited or created this myself.
2010-01-05 22:33:41 +00:00
=bmesh= fixed edge split modifier, and a bug in knifetool reported by letterrip. also brought back beautify-fill.
2011-04-22 23:37:58 +00:00
if (!CustomData_has_layer(&dm->edgeData, CD_MEDGE))
CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_ASSIGN, medge, dm->numEdgeData);
rewrote edge split modifier to be simpler and hopefully faster. and of course it handles ngons properly now.
2009-09-11 10:21:54 +00:00
cddm->medge = medge;
}
void CDDM_set_mface(DerivedMesh *dm, MFace *mface)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Got rid of old multires code, brought in multires modifier from soc-2008-nicholasbishop branch. Note: any old code with multires_test() or multires_level1_test() can just be deleted, not needed by the multires modifier.
2009-01-06 18:59:03 +00:00
=bmesh= fixed edge split modifier, and a bug in knifetool reported by letterrip. also brought back beautify-fill.
2011-04-22 23:37:58 +00:00
if (!CustomData_has_layer(&dm->faceData, CD_MFACE))
More DM func renames, fixing some build breaks, renaming more stuff, also seems like it might be fixing the recent CDDM_copy corruption/leak bug
2011-11-30 18:03:56 +00:00
CustomData_add_layer(&dm->faceData, CD_MFACE, CD_ASSIGN, mface, dm->numTessFaceData);
=bmesh= fixed edge split modifier, and a bug in knifetool reported by letterrip. also brought back beautify-fill.
2011-04-22 23:37:58 +00:00
Merge with trunk/2.5 at r25563 Most likely will not compile for others, I'd appreciate any build errors and missing files reports (I can never seem to get everything committed and all the build systems working without help). Porting over the sculpt/multires tools was a breeze, thanks goes to brecht for a design that didn't exclude ngons and was easy to port. Note that I've not tested externally-backed multires file support yet. Also, I still need to write version patch code for some cases. Some notes: * Like trunk, topological changes don't update multires right, so e.g. subdivide will duplicate multires data on the new faces, instead of subdividing it. * If you set the debug value (ctrl-alt-d) to 1 it'll turn on my experiments in speeding up sculpting on higher-res multires meshes (but note it makes partial redraw not completely accurate). * There's a bug where you have to go through editmode to get out of sculpt mode, not sure if I inherited or created this myself.
2010-01-05 22:33:41 +00:00
cddm->mface = mface;
Got rid of old multires code, brought in multires modifier from soc-2008-nicholasbishop branch. Note: any old code with multires_test() or multires_level1_test() can just be deleted, not needed by the multires modifier.
2009-01-06 18:59:03 +00:00
}
Code Cleanup: remove non existing function declarations. added some missing functions too - which are not used yep but should be there for api completeness. * CDDM_set_mloop * CDDM_set_mpoly * BLI_mempool_count
2012-02-29 15:00:37 +00:00
void CDDM_set_mloop(DerivedMesh *dm, MLoop *mloop)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code Cleanup: remove non existing function declarations. added some missing functions too - which are not used yep but should be there for api completeness. * CDDM_set_mloop * CDDM_set_mpoly * BLI_mempool_count
2012-02-29 15:00:37 +00:00
if (!CustomData_has_layer(&dm->loopData, CD_MLOOP))
CustomData_add_layer(&dm->loopData, CD_MLOOP, CD_ASSIGN, mloop, dm->numLoopData);
cddm->mloop = mloop;
}
void CDDM_set_mpoly(DerivedMesh *dm, MPoly *mpoly)
{
style cleanup: blenkernel
2012-05-06 17:22:54 +00:00
CDDerivedMesh *cddm = (CDDerivedMesh *)dm;
Code Cleanup: remove non existing function declarations. added some missing functions too - which are not used yep but should be there for api completeness. * CDDM_set_mloop * CDDM_set_mpoly * BLI_mempool_count
2012-02-29 15:00:37 +00:00
if (!CustomData_has_layer(&dm->polyData, CD_MPOLY))
CustomData_add_layer(&dm->polyData, CD_MPOLY, CD_ASSIGN, mpoly, dm->numPolyData);
cddm->mpoly = mpoly;
}
Copy Permalink