tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/source/blender/blenkernel/intern/DerivedMesh.c

3548 lines
97 KiB
C
Raw Normal View History

NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
/**
* $Id$
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-17 00:40:48 +02:00
* ***** BEGIN GPL LICENSE BLOCK *****
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-17 00:40:48 +02:00
* of the License, or (at your option) any later version.
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*
- added Mesh->derived and Mesh->decimated DerivedMesh pointers - removed DL_MESH displist type!!!! Now store a DerivedMesh directly. - May still be some issues left having to do with releasing this at the right time (old code just splashed free_displist all over the place).
2005-03-29 18:43:39 +02:00
* The Original Code is Copyright (C) 2005 Blender Foundation.
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
* All rights reserved.
*
* The Original Code is: all of this file.
*
* Contributor(s): none yet.
*
Patch from GSR that a) fixes a whole bunch of GPL/BL license blocks that were previously missed; and b) greatly increase my ohloh stats!
2008-04-17 00:40:48 +02:00
* ***** END GPL LICENSE BLOCK *****
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
*/
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
#include <string.h>
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#ifdef HAVE_CONFIG_H
#include <config.h>
#endif
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
#include <zlib.h>
- added ModifierData flag, is modifier enabled in editmode - added modifier type flag: should modifier be enabled by default for active in editmode - added subsurf "debug incremental" option instead of G.rt==52 (it becomes a slightly useful feature now for debugging how well a modifier works with incremental subsurf... maybe important for future python modifier developers) - shuffled modifier button layout just to keep people guessing - switched back to drawing editmesh face centers not through derivedmesh, I didn't think this one through, forgot that centers were also used for selection. have to think about what to do about this, should be either (a) don't draw centers with a cage active (optimal mode) or (b) come up with api to draw centers through derivedmesh and also handle selection. - changed recalc_editnormals to also follow the len(no)==0.0 use vertex co convention
2005-07-23 21:15:08 +02:00
#include "PIL_time.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "MEM_guardedalloc.h"
#include "DNA_effect_types.h"
#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 03:12:36 +02:00
#include "DNA_key_types.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "DNA_meshdata_types.h"
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
#include "DNA_modifier_types.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "DNA_object_types.h"
Changed test for (me->flag&ME_SUBSURF) into ((me->flag&ME_SUBSURF) && me->subdiv) In build_mesh_data(). This because meshes with subdiv==0 were calling a MakeDisplist() for each redraw otherwise, disabling for example the posemode "delay deform" feature. (bug #2700) Daniel; it would help if you would add comments in the code, for example to understand the difference between; mesh_get_base_derived() mesh_get_derived() and how it relates to build_mesh_data() I realize most of the mess is in displist code... and confusing use of features while editing, posemode, & render. Nevertheless, it's not clear at first sight which parts of derivedmesh is design, and which part reflects the hacks to make it work. :)
2005-06-06 11:52:44 +02:00
#include "DNA_object_force.h"
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
#include "DNA_object_fluidsim.h" // N_T
#include "DNA_scene_types.h" // N_T
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
#include "DNA_texture_types.h"
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
#include "DNA_view3d_types.h"
#include "DNA_screen_types.h"
#include "DNA_space_types.h"
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
#include "DNA_particle_types.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
#include "BLI_arithb.h"
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
#include "BLI_blenlib.h"
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
#include "BLI_edgehash.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "BLI_editVert.h"
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
#include "BLI_linklist.h"
Game Engine: alpha blending and sorting ======================================= Alpha blending + sorting was revised, to fix bugs and get it to work more predictable. * A new per texture face "Sort" setting defines if the face is alpha sorted or not, instead of abusing the "ZTransp" setting as it did before. * Existing files are converted to hopefully match the old behavior as much as possible with a version patch. * On new meshes the Sort flag is disabled by the default, to avoid unexpected and hard to find slowdowns. * Alpha sorting for faces was incredibly slow. Sorting faces in a mesh with 600 faces lowered the framerate from 200 to 70 fps in my test.. the sorting there case goes about 15x faster now, but it is still advised to use Clip Alpha if possible instead of regular Alpha. * There still various limitations in the alpha sorting code, I've added some comments to the code about this. Some docs at the bottom of the page: http://www.blender.org/development/current-projects/changes-since-246/realtime-glsl-materials/ Merged some fixes from the apricot branch, most important change is that tangents are now exactly the same as the rest of Blender, instead of being computed in the game engine with a different algorithm. Also, the subversion was bumped to 1.
2008-07-29 17:48:31 +02:00
#include "BLI_memarena.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +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 03:12:36 +02:00
#include "BKE_cdderivedmesh.h"
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 17:38:37 +01:00
#include "BKE_customdata.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "BKE_DerivedMesh.h"
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
#include "BKE_deform.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "BKE_displist.h"
#include "BKE_effect.h"
#include "BKE_global.h"
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
#include "BKE_key.h"
- added drawFacesTex function to DerivedMesh with implementations - switched drawmesh.c to use new functions - WHEE! This is last such function that has to be written for the time being, and also effectively marks the end of DL_MESH! DispListMesh still hangs around as a kind of interchange format but should also die once DerivedMesh provides more intimate mesh access. DL_MESH (the displist type for DispListMesh) is still used to hold the DispListMesh, but that will die as soon as new subsurf switches to using a bonafide DerivedMesh implementation. There is also one silly usage for the decimator that is easy to kill. - Oh, and I also made potatoe mode draw mesh vertex colors - seemed to be more uniform behavior.
2005-03-29 09:51:00 +02:00
#include "BKE_material.h"
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
#include "BKE_modifier.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "BKE_mesh.h"
== Multires == Cleaned up bad level calls for multires; moved most of multires functions to blenkern, where they should have been in the first place. Functionality of the tool is unchanged.
2007-12-26 10:39:15 +01:00
#include "BKE_multires.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "BKE_object.h"
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
#include "BKE_subsurf.h"
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
#include "BKE_texture.h"
#include "BKE_utildefines.h"
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
#include "BKE_particle.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#ifdef WITH_VERSE
#include "BKE_verse.h"
#endif
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
#include "BIF_gl.h"
#include "BIF_glutil.h"
- fixed elbeem header include problems
2006-03-29 16:57:14 +02:00
// headers for fluidsim bobj meshes
#include <stdlib.h>
#include "LBM_fluidsim.h"
#include "elbeem.h"
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
///////////////////////////////////
///////////////////////////////////
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MVert *dm_getVertArray(DerivedMesh *dm)
{
MVert *mvert = CustomData_get_layer(&dm->vertData, CD_MVERT);
if (!mvert) {
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 22:29:09 +01:00
mvert = CustomData_add_layer(&dm->vertData, CD_MVERT, CD_CALLOC, NULL,
dm->getNumVerts(dm));
CustomData_set_layer_flag(&dm->vertData, CD_MVERT, CD_FLAG_TEMPORARY);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->copyVertArray(dm, mvert);
}
return mvert;
}
MEdge *dm_getEdgeArray(DerivedMesh *dm)
{
MEdge *medge = CustomData_get_layer(&dm->edgeData, CD_MEDGE);
if (!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 22:29:09 +01:00
medge = CustomData_add_layer(&dm->edgeData, CD_MEDGE, CD_CALLOC, NULL,
dm->getNumEdges(dm));
CustomData_set_layer_flag(&dm->edgeData, CD_MEDGE, CD_FLAG_TEMPORARY);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->copyEdgeArray(dm, medge);
}
return medge;
}
MFace *dm_getFaceArray(DerivedMesh *dm)
{
MFace *mface = CustomData_get_layer(&dm->faceData, CD_MFACE);
if (!mface) {
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 22:29:09 +01:00
mface = CustomData_add_layer(&dm->faceData, CD_MFACE, CD_CALLOC, NULL,
dm->getNumFaces(dm));
CustomData_set_layer_flag(&dm->faceData, CD_MFACE, CD_FLAG_TEMPORARY);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->copyFaceArray(dm, mface);
}
return 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 03:12:36 +02:00
MVert *dm_dupVertArray(DerivedMesh *dm)
{
MVert *tmp = MEM_callocN(sizeof(*tmp) * dm->getNumVerts(dm),
"dm_dupVertArray tmp");
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(tmp) dm->copyVertArray(dm, tmp);
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 03:12:36 +02:00
return tmp;
}
MEdge *dm_dupEdgeArray(DerivedMesh *dm)
{
MEdge *tmp = MEM_callocN(sizeof(*tmp) * dm->getNumEdges(dm),
"dm_dupEdgeArray tmp");
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(tmp) dm->copyEdgeArray(dm, tmp);
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 03:12:36 +02:00
return tmp;
}
MFace *dm_dupFaceArray(DerivedMesh *dm)
{
MFace *tmp = MEM_callocN(sizeof(*tmp) * dm->getNumFaces(dm),
"dm_dupFaceArray tmp");
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(tmp) dm->copyFaceArray(dm, tmp);
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 03:12:36 +02:00
return tmp;
}
void DM_init_funcs(DerivedMesh *dm)
{
/* default function implementations */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->getVertArray = dm_getVertArray;
dm->getEdgeArray = dm_getEdgeArray;
dm->getFaceArray = dm_getFaceArray;
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 03:12:36 +02:00
dm->dupVertArray = dm_dupVertArray;
dm->dupEdgeArray = dm_dupEdgeArray;
dm->dupFaceArray = dm_dupFaceArray;
dm->getVertData = DM_get_vert_data;
dm->getEdgeData = DM_get_edge_data;
dm->getFaceData = DM_get_face_data;
dm->getVertDataArray = DM_get_vert_data_layer;
dm->getEdgeDataArray = DM_get_edge_data_layer;
dm->getFaceDataArray = DM_get_face_data_layer;
}
void DM_init(DerivedMesh *dm,
int numVerts, int numEdges, int numFaces)
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->numVertData = numVerts;
dm->numEdgeData = numEdges;
dm->numFaceData = numFaces;
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 03:12:36 +02:00
DM_init_funcs(dm);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->needsFree = 1;
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 03:12:36 +02:00
}
void DM_from_template(DerivedMesh *dm, DerivedMesh *source,
int numVerts, int numEdges, int numFaces)
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CustomData_copy(&source->vertData, &dm->vertData, CD_MASK_DERIVEDMESH,
CD_CALLOC, numVerts);
CustomData_copy(&source->edgeData, &dm->edgeData, CD_MASK_DERIVEDMESH,
CD_CALLOC, numEdges);
CustomData_copy(&source->faceData, &dm->faceData, CD_MASK_DERIVEDMESH,
CD_CALLOC, numFaces);
dm->numVertData = numVerts;
dm->numEdgeData = numEdges;
dm->numFaceData = numFaces;
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 03:12:36 +02:00
DM_init_funcs(dm);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->needsFree = 1;
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 03:12:36 +02:00
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
int DM_release(DerivedMesh *dm)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if (dm->needsFree) {
CustomData_free(&dm->vertData, dm->numVertData);
CustomData_free(&dm->edgeData, dm->numEdgeData);
CustomData_free(&dm->faceData, dm->numFaceData);
return 1;
}
else {
CustomData_free_temporary(&dm->vertData, dm->numVertData);
CustomData_free_temporary(&dm->edgeData, dm->numEdgeData);
CustomData_free_temporary(&dm->faceData, dm->numFaceData);
return 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 03:12:36 +02:00
}
void DM_to_mesh(DerivedMesh *dm, Mesh *me)
{
/* dm might depend on me, so we need to do everything with a local copy */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
Mesh tmp = *me;
int totvert, totedge, totface;
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
memset(&tmp.vdata, 0, sizeof(tmp.vdata));
memset(&tmp.edata, 0, sizeof(tmp.edata));
memset(&tmp.fdata, 0, sizeof(tmp.fdata));
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
totvert = tmp.totvert = dm->getNumVerts(dm);
totedge = tmp.totedge = dm->getNumEdges(dm);
totface = tmp.totface = dm->getNumFaces(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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CustomData_copy(&dm->vertData, &tmp.vdata, CD_MASK_MESH, CD_DUPLICATE, totvert);
CustomData_copy(&dm->edgeData, &tmp.edata, CD_MASK_MESH, CD_DUPLICATE, totedge);
CustomData_copy(&dm->faceData, &tmp.fdata, CD_MASK_MESH, CD_DUPLICATE, totface);
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
/* not all DerivedMeshes store their verts/edges/faces in CustomData, so
we set them here in case they are missing */
if(!CustomData_has_layer(&tmp.vdata, CD_MVERT))
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 22:29:09 +01:00
CustomData_add_layer(&tmp.vdata, CD_MVERT, CD_ASSIGN, dm->dupVertArray(dm), totvert);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(!CustomData_has_layer(&tmp.edata, 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 22:29:09 +01:00
CustomData_add_layer(&tmp.edata, CD_MEDGE, CD_ASSIGN, dm->dupEdgeArray(dm), totedge);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(!CustomData_has_layer(&tmp.fdata, CD_MFACE))
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 22:29:09 +01:00
CustomData_add_layer(&tmp.fdata, CD_MFACE, CD_ASSIGN, dm->dupFaceArray(dm), totface);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
mesh_update_customdata_pointers(&tmp);
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CustomData_free(&me->vdata, me->totvert);
CustomData_free(&me->edata, me->totedge);
CustomData_free(&me->fdata, me->totface);
/* if the number of verts has changed, remove invalid data */
if(tmp.totvert != me->totvert) {
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 03:12:36 +02:00
if(me->key) me->key->id.us--;
me->key = NULL;
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
*me = tmp;
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 03:12:36 +02:00
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
void DM_set_only_copy(DerivedMesh *dm, CustomDataMask mask)
{
CustomData_set_only_copy(&dm->vertData, mask);
CustomData_set_only_copy(&dm->edgeData, mask);
CustomData_set_only_copy(&dm->faceData, mask);
}
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 22:29:09 +01:00
void DM_add_vert_layer(DerivedMesh *dm, int type, int alloctype, void *layer)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02: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 22:29:09 +01:00
CustomData_add_layer(&dm->vertData, type, alloctype, layer, 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 03:12:36 +02: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 22:29:09 +01:00
void DM_add_edge_layer(DerivedMesh *dm, int type, int alloctype, void *layer)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02: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 22:29:09 +01:00
CustomData_add_layer(&dm->edgeData, type, alloctype, layer, 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 03:12:36 +02: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 22:29:09 +01:00
void DM_add_face_layer(DerivedMesh *dm, int type, int alloctype, void *layer)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02: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 22:29:09 +01:00
CustomData_add_layer(&dm->faceData, type, alloctype, layer, dm->numFaceData);
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 03:12:36 +02:00
}
void *DM_get_vert_data(DerivedMesh *dm, int index, int type)
{
return CustomData_get(&dm->vertData, index, type);
}
void *DM_get_edge_data(DerivedMesh *dm, int index, int type)
{
return CustomData_get(&dm->edgeData, index, type);
}
void *DM_get_face_data(DerivedMesh *dm, int index, int type)
{
return CustomData_get(&dm->faceData, index, type);
}
void *DM_get_vert_data_layer(DerivedMesh *dm, int type)
{
return CustomData_get_layer(&dm->vertData, type);
}
void *DM_get_edge_data_layer(DerivedMesh *dm, int type)
{
return CustomData_get_layer(&dm->edgeData, type);
}
void *DM_get_face_data_layer(DerivedMesh *dm, int type)
{
return CustomData_get_layer(&dm->faceData, type);
}
void DM_set_vert_data(DerivedMesh *dm, int index, int type, void *data)
{
CustomData_set(&dm->vertData, index, type, data);
}
void DM_set_edge_data(DerivedMesh *dm, int index, int type, void *data)
{
CustomData_set(&dm->edgeData, index, type, data);
}
void DM_set_face_data(DerivedMesh *dm, int index, int type, void *data)
{
CustomData_set(&dm->faceData, index, type, data);
}
void DM_copy_vert_data(DerivedMesh *source, DerivedMesh *dest,
int source_index, int dest_index, int count)
{
CustomData_copy_data(&source->vertData, &dest->vertData,
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
source_index, dest_index, count);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
}
void DM_copy_edge_data(DerivedMesh *source, DerivedMesh *dest,
int source_index, int dest_index, int count)
{
CustomData_copy_data(&source->edgeData, &dest->edgeData,
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
source_index, dest_index, count);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
}
void DM_copy_face_data(DerivedMesh *source, DerivedMesh *dest,
int source_index, int dest_index, int count)
{
CustomData_copy_data(&source->faceData, &dest->faceData,
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
source_index, dest_index, count);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
}
void DM_free_vert_data(struct DerivedMesh *dm, int index, int count)
{
CustomData_free_elem(&dm->vertData, index, count);
}
void DM_free_edge_data(struct DerivedMesh *dm, int index, int count)
{
CustomData_free_elem(&dm->edgeData, index, count);
}
void DM_free_face_data(struct DerivedMesh *dm, int index, int count)
{
CustomData_free_elem(&dm->faceData, index, count);
}
void DM_interp_vert_data(DerivedMesh *source, DerivedMesh *dest,
int *src_indices, float *weights,
int count, int dest_index)
{
CustomData_interp(&source->vertData, &dest->vertData, src_indices,
weights, NULL, count, dest_index);
}
void DM_interp_edge_data(DerivedMesh *source, DerivedMesh *dest,
int *src_indices,
float *weights, EdgeVertWeight *vert_weights,
int count, int dest_index)
{
CustomData_interp(&source->edgeData, &dest->edgeData, src_indices,
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 17:38:37 +01:00
weights, (float*)vert_weights, count, dest_index);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
}
void DM_interp_face_data(DerivedMesh *source, DerivedMesh *dest,
int *src_indices,
float *weights, FaceVertWeight *vert_weights,
int count, int dest_index)
{
CustomData_interp(&source->faceData, &dest->faceData, src_indices,
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 17:38:37 +01:00
weights, (float*)vert_weights, count, dest_index);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
}
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void DM_swap_face_data(DerivedMesh *dm, int index, int *corner_indices)
- convert mesh_modifier to return deformed verts instead of leaving in a DL_VERTS type displist (and modifying mesh) - removed DL_VERTS displist type (woot woot) - makeDispListMesh now puts deformed verts in object->derivedDeform - switch over other system parts to new deformed vert storage, still kinda hacky and maybe some inconsistencies... will be sorted out soon enough. - moved build_particle_system to makeDispListMesh... this may have adverse side effects, needs to be sorted out with depgraph system
2005-07-17 19:41:03 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CustomData_swap(&dm->faceData, index, corner_indices);
- convert mesh_modifier to return deformed verts instead of leaving in a DL_VERTS type displist (and modifying mesh) - removed DL_VERTS displist type (woot woot) - makeDispListMesh now puts deformed verts in object->derivedDeform - switch over other system parts to new deformed vert storage, still kinda hacky and maybe some inconsistencies... will be sorted out soon enough. - moved build_particle_system to makeDispListMesh... this may have adverse side effects, needs to be sorted out with depgraph system
2005-07-17 19:41:03 +02:00
}
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
static DerivedMesh *getMeshDerivedMesh(Mesh *me, Object *ob, float (*vertCos)[3])
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
DerivedMesh *dm = CDDM_from_mesh(me, ob);
int i, dofluidsim;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dofluidsim = ((ob->fluidsimFlag & OB_FLUIDSIM_ENABLE) &&
(ob->fluidsimSettings->type & OB_FLUIDSIM_DOMAIN)&&
(ob->fluidsimSettings->meshSurface) &&
(me->totvert == ((Mesh *)(ob->fluidsimSettings->meshSurface))->totvert));
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if (vertCos && !dofluidsim)
CDDM_apply_vert_coords(dm, vertCos);
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CDDM_calc_normals(dm);
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
/* apply fluidsim normals */
if (dofluidsim) {
// use normals from readBobjgz
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
// TODO? check for modifiers!?
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MVert *fsvert = ob->fluidsimSettings->meshSurfNormals;
short (*normals)[3] = MEM_mallocN(sizeof(short)*3*me->totvert, "fluidsim nor");
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
for (i=0; i<me->totvert; i++) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
VECCOPY(normals[i], fsvert[i].no);
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
//mv->no[0]= 30000; mv->no[1]= mv->no[2]= 0; // DEBUG fixed test 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 05:28:02 +01:00
CDDM_apply_vert_normals(dm, normals);
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MEM_freeN(normals);
}
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
return dm;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
///
typedef struct {
DerivedMesh dm;
EditMesh *em;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
float (*vertexCos)[3];
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
float (*vertexNos)[3];
float (*faceNos)[3];
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
} EditMeshDerivedMesh;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
static void emDM_foreachMappedVert(DerivedMesh *dm, void (*func)(void *userData, int index, float *co, float *no_f, short *no_s), void *userData)
- added getMappedVertCoEM and drawMappedVertEM to DerivedMesh with implementations (slightly redundant, could implement draw in terms of first... can be cleaned later) - switch to use of new APIs... all uses of EditVert->ssco are now clean (read: ready to die as soon as a proper DerivedMesh implementation is swapped in with ccgsubsurf)
2005-03-28 09:10:32 +02:00
{
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
Big commit, had to rework lots of selection stuff so that things worked properly with modifiers. Needs more testing I am sure. No, honestly, I wasn't just cleaning for the hell of it, it was *necessary* (I would never do such a thing). Selection should work completely with cage options of modifiers now. - added DerivedMesh foreach functions to iterate over mapped verts/edges/face centers. These replaced some of the drawing functions and are more general anyway. Special edge drawing functions remain for performance reasons. - removed EditFace xs, ys fields - added general functions to iterate over screen coordinates of mesh/curve/lattice objects - removed all calc_*verts* functions that were used for storing screen coordinates in objects. they were recalc'd on the fly for most situations anyway, so now we just always do that. calc_*verts_ext was one of those calls that did dirty things deep down in the callstack (changing curarea and poking at matrices) - rewrote all vertex level selection routines (circle, lasso, bbox) and closest vertex routines (rightmouse select) to use the new system. This cleaned up the selection code a lot and the structure of selection is much easier to see now. This is good for future work on allowing modifiers to completely override the selection system. It also points out some discrepancies in the way selection is handled that might be nice to resolve (mesh vertex selection has fancy stuff to try to help with selecting overlapping, but it only works w/o bbuf select, and curves/lattices don't have at all). - had to remove ton's code to move Manipulator to cage location, this is not reliable (can come up with a different method if requested) - as it happens BezTriple.s and BPoint.s are basically available to be removed, just need to rewrite editipo code that still does background calc of screen coordinates - MVert.{xs,ys} are still around because they are abused in some places for other info (not sure if this is safe actually, since they are short's and the mvert limit went up). And did I mention this commit is comes out to -305 lines? Well it does.
2005-08-09 10:12:36 +02:00
EditVert *eve;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
int i;
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for (i=0,eve= emdm->em->verts.first; eve; i++,eve=eve->next) {
if (emdm->vertexCos) {
func(userData, i, emdm->vertexCos[i], emdm->vertexNos[i], NULL);
} else {
func(userData, i, eve->co, eve->no, NULL);
Big commit, had to rework lots of selection stuff so that things worked properly with modifiers. Needs more testing I am sure. No, honestly, I wasn't just cleaning for the hell of it, it was *necessary* (I would never do such a thing). Selection should work completely with cage options of modifiers now. - added DerivedMesh foreach functions to iterate over mapped verts/edges/face centers. These replaced some of the drawing functions and are more general anyway. Special edge drawing functions remain for performance reasons. - removed EditFace xs, ys fields - added general functions to iterate over screen coordinates of mesh/curve/lattice objects - removed all calc_*verts* functions that were used for storing screen coordinates in objects. they were recalc'd on the fly for most situations anyway, so now we just always do that. calc_*verts_ext was one of those calls that did dirty things deep down in the callstack (changing curarea and poking at matrices) - rewrote all vertex level selection routines (circle, lasso, bbox) and closest vertex routines (rightmouse select) to use the new system. This cleaned up the selection code a lot and the structure of selection is much easier to see now. This is good for future work on allowing modifiers to completely override the selection system. It also points out some discrepancies in the way selection is handled that might be nice to resolve (mesh vertex selection has fancy stuff to try to help with selecting overlapping, but it only works w/o bbuf select, and curves/lattices don't have at all). - had to remove ton's code to move Manipulator to cage location, this is not reliable (can come up with a different method if requested) - as it happens BezTriple.s and BPoint.s are basically available to be removed, just need to rewrite editipo code that still does background calc of screen coordinates - MVert.{xs,ys} are still around because they are abused in some places for other info (not sure if this is safe actually, since they are short's and the mvert limit went up). And did I mention this commit is comes out to -305 lines? Well it does.
2005-08-09 10:12:36 +02:00
}
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
}
- added getMappedVertCoEM and drawMappedVertEM to DerivedMesh with implementations (slightly redundant, could implement draw in terms of first... can be cleaned later) - switch to use of new APIs... all uses of EditVert->ssco are now clean (read: ready to die as soon as a proper DerivedMesh implementation is swapped in with ccgsubsurf)
2005-03-28 09:10:32 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
static void emDM_foreachMappedEdge(DerivedMesh *dm, void (*func)(void *userData, int index, float *v0co, float *v1co), void *userData)
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
Big commit, had to rework lots of selection stuff so that things worked properly with modifiers. Needs more testing I am sure. No, honestly, I wasn't just cleaning for the hell of it, it was *necessary* (I would never do such a thing). Selection should work completely with cage options of modifiers now. - added DerivedMesh foreach functions to iterate over mapped verts/edges/face centers. These replaced some of the drawing functions and are more general anyway. Special edge drawing functions remain for performance reasons. - removed EditFace xs, ys fields - added general functions to iterate over screen coordinates of mesh/curve/lattice objects - removed all calc_*verts* functions that were used for storing screen coordinates in objects. they were recalc'd on the fly for most situations anyway, so now we just always do that. calc_*verts_ext was one of those calls that did dirty things deep down in the callstack (changing curarea and poking at matrices) - rewrote all vertex level selection routines (circle, lasso, bbox) and closest vertex routines (rightmouse select) to use the new system. This cleaned up the selection code a lot and the structure of selection is much easier to see now. This is good for future work on allowing modifiers to completely override the selection system. It also points out some discrepancies in the way selection is handled that might be nice to resolve (mesh vertex selection has fancy stuff to try to help with selecting overlapping, but it only works w/o bbuf select, and curves/lattices don't have at all). - had to remove ton's code to move Manipulator to cage location, this is not reliable (can come up with a different method if requested) - as it happens BezTriple.s and BPoint.s are basically available to be removed, just need to rewrite editipo code that still does background calc of screen coordinates - MVert.{xs,ys} are still around because they are abused in some places for other info (not sure if this is safe actually, since they are short's and the mvert limit went up). And did I mention this commit is comes out to -305 lines? Well it does.
2005-08-09 10:12:36 +02:00
EditEdge *eed;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
int i;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
if (emdm->vertexCos) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *eve;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
Big commit, had to rework lots of selection stuff so that things worked properly with modifiers. Needs more testing I am sure. No, honestly, I wasn't just cleaning for the hell of it, it was *necessary* (I would never do such a thing). Selection should work completely with cage options of modifiers now. - added DerivedMesh foreach functions to iterate over mapped verts/edges/face centers. These replaced some of the drawing functions and are more general anyway. Special edge drawing functions remain for performance reasons. - removed EditFace xs, ys fields - added general functions to iterate over screen coordinates of mesh/curve/lattice objects - removed all calc_*verts* functions that were used for storing screen coordinates in objects. they were recalc'd on the fly for most situations anyway, so now we just always do that. calc_*verts_ext was one of those calls that did dirty things deep down in the callstack (changing curarea and poking at matrices) - rewrote all vertex level selection routines (circle, lasso, bbox) and closest vertex routines (rightmouse select) to use the new system. This cleaned up the selection code a lot and the structure of selection is much easier to see now. This is good for future work on allowing modifiers to completely override the selection system. It also points out some discrepancies in the way selection is handled that might be nice to resolve (mesh vertex selection has fancy stuff to try to help with selecting overlapping, but it only works w/o bbuf select, and curves/lattices don't have at all). - had to remove ton's code to move Manipulator to cage location, this is not reliable (can come up with a different method if requested) - as it happens BezTriple.s and BPoint.s are basically available to be removed, just need to rewrite editipo code that still does background calc of screen coordinates - MVert.{xs,ys} are still around because they are abused in some places for other info (not sure if this is safe actually, since they are short's and the mvert limit went up). And did I mention this commit is comes out to -305 lines? Well it does.
2005-08-09 10:12:36 +02:00
for (i=0,eve=emdm->em->verts.first; eve; eve= eve->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
eve->tmp.l = (long) i++;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for(i=0,eed= emdm->em->edges.first; eed; i++,eed= eed->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
func(userData, i, emdm->vertexCos[(int) eed->v1->tmp.l], emdm->vertexCos[(int) eed->v2->tmp.l]);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
} else {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for(i=0,eed= emdm->em->edges.first; eed; i++,eed= eed->next)
func(userData, i, eed->v1->co, eed->v2->co);
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
static void emDM_drawMappedEdges(DerivedMesh *dm, int (*setDrawOptions)(void *userData, int index), void *userData)
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
EditEdge *eed;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
int i;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
if (emdm->vertexCos) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *eve;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
for (i=0,eve=emdm->em->verts.first; eve; eve= eve->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
eve->tmp.l = (long) i++;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glBegin(GL_LINES);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for(i=0,eed= emdm->em->edges.first; eed; i++,eed= eed->next) {
if(!setDrawOptions || setDrawOptions(userData, i)) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
glVertex3fv(emdm->vertexCos[(int) eed->v1->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) eed->v2->tmp.l]);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glEnd();
} else {
glBegin(GL_LINES);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for(i=0,eed= emdm->em->edges.first; eed; i++,eed= eed->next) {
if(!setDrawOptions || setDrawOptions(userData, i)) {
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glVertex3fv(eed->v1->co);
glVertex3fv(eed->v2->co);
}
}
glEnd();
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
- cleaned up edge drawing a tad, there were issues with mesh's with "loose" edges (edges without a face) and drawing in solid mode. they would either not draw, or draw with a nasty selection outline. Added a ME_LOOSEEDGE flag to mark such edges in displists/mesh and editmode sets it. - changed DerivedMesh drawEdges to take an argument whether it should draw loose edges or not
2005-08-14 12:35:58 +02:00
static void emDM_drawEdges(DerivedMesh *dm, int drawLooseEdges)
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
{
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
emDM_drawMappedEdges(dm, NULL, NULL);
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
static void emDM_drawMappedEdgesInterp(DerivedMesh *dm, int (*setDrawOptions)(void *userData, int index), void (*setDrawInterpOptions)(void *userData, int index, float t), void *userData)
- added drawMapped{Verts,Edges,Faces}EMSelect calls to DerivedMesh with implementations - updated drawobject selection code to use DerivedMesh (last DispListMesh usage in drawobject.c that needs to be replaced! Woot!) - interface could still be a lot cleaner, mostly calculating indices for the various things to pass to selection color routine is hacky.
2005-03-28 08:46:21 +02:00
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
EditEdge *eed;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
int i;
- added drawMapped{Verts,Edges,Faces}EMSelect calls to DerivedMesh with implementations - updated drawobject selection code to use DerivedMesh (last DispListMesh usage in drawobject.c that needs to be replaced! Woot!) - interface could still be a lot cleaner, mostly calculating indices for the various things to pass to selection color routine is hacky.
2005-03-28 08:46:21 +02:00
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
if (emdm->vertexCos) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *eve;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
for (i=0,eve=emdm->em->verts.first; eve; eve= eve->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
eve->tmp.l = (long) i++;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glBegin(GL_LINES);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for (i=0,eed= emdm->em->edges.first; eed; i++,eed= eed->next) {
if(!setDrawOptions || setDrawOptions(userData, i)) {
setDrawInterpOptions(userData, i, 0.0);
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
glVertex3fv(emdm->vertexCos[(int) eed->v1->tmp.l]);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
setDrawInterpOptions(userData, i, 1.0);
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
glVertex3fv(emdm->vertexCos[(int) eed->v2->tmp.l]);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
- added drawMapped{Verts,Edges,Faces}EMSelect calls to DerivedMesh with implementations - updated drawobject selection code to use DerivedMesh (last DispListMesh usage in drawobject.c that needs to be replaced! Woot!) - interface could still be a lot cleaner, mostly calculating indices for the various things to pass to selection color routine is hacky.
2005-03-28 08:46:21 +02:00
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glEnd();
} else {
glBegin(GL_LINES);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for (i=0,eed= emdm->em->edges.first; eed; i++,eed= eed->next) {
if(!setDrawOptions || setDrawOptions(userData, i)) {
setDrawInterpOptions(userData, i, 0.0);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glVertex3fv(eed->v1->co);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
setDrawInterpOptions(userData, i, 1.0);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glVertex3fv(eed->v2->co);
}
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glEnd();
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
}
Fixed all gcc 4 warnings in blenkernel. Found 2 potentially harmful unintialized variables in the verse code, verse_session.c:451 and verse_object_node.c:339, those are properly initialized now.
2006-10-27 01:34:44 +02:00
static void emDM_drawUVEdges(DerivedMesh *dm)
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
EditFace *efa;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MTFace *tf;
Fixed all gcc 4 warnings in blenkernel. Found 2 potentially harmful unintialized variables in the verse code, verse_session.c:451 and verse_object_node.c:339, those are properly initialized now.
2006-10-27 01:34:44 +02:00
glBegin(GL_LINES);
for(efa= emdm->em->faces.first; efa; efa= efa->next) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
tf = CustomData_em_get(&emdm->em->fdata, efa->data, CD_MTFACE);
Fixed all gcc 4 warnings in blenkernel. Found 2 potentially harmful unintialized variables in the verse code, verse_session.c:451 and verse_object_node.c:339, those are properly initialized now.
2006-10-27 01:34:44 +02:00
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 15:39:46 +02:00
if(tf && !(efa->h)) {
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 17:38:37 +01:00
glVertex2fv(tf->uv[0]);
glVertex2fv(tf->uv[1]);
glVertex2fv(tf->uv[1]);
glVertex2fv(tf->uv[2]);
Fixed all gcc 4 warnings in blenkernel. Found 2 potentially harmful unintialized variables in the verse code, verse_session.c:451 and verse_object_node.c:339, those are properly initialized now.
2006-10-27 01:34:44 +02:00
if (!efa->v4) {
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 17:38:37 +01:00
glVertex2fv(tf->uv[2]);
glVertex2fv(tf->uv[0]);
Fixed all gcc 4 warnings in blenkernel. Found 2 potentially harmful unintialized variables in the verse code, verse_session.c:451 and verse_object_node.c:339, those are properly initialized now.
2006-10-27 01:34:44 +02:00
} else {
Added custom face data support in edit mode. The code used to do this is the CustomData module from the modifier stack rewrite, but with additions to make it also usable in edit mode. Some of the datatypes from that module were move to a DNA header file, they are not saved to file now, but will be soon. The only code that wasn't abstracted is the uv collapse / merging code. It is rather complicated, will look into that in the future. There should be no user level changes.
2006-11-11 17:38:37 +01:00
glVertex2fv(tf->uv[2]);
glVertex2fv(tf->uv[3]);
glVertex2fv(tf->uv[3]);
glVertex2fv(tf->uv[0]);
Fixed all gcc 4 warnings in blenkernel. Found 2 potentially harmful unintialized variables in the verse code, verse_session.c:451 and verse_object_node.c:339, those are properly initialized now.
2006-10-27 01:34:44 +02:00
}
}
}
glEnd();
}
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
static void emDM__calcFaceCent(EditFace *efa, float cent[3], float (*vertexCos)[3])
{
if (vertexCos) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
VECCOPY(cent, vertexCos[(int) efa->v1->tmp.l]);
VecAddf(cent, cent, vertexCos[(int) efa->v2->tmp.l]);
VecAddf(cent, cent, vertexCos[(int) efa->v3->tmp.l]);
if (efa->v4) VecAddf(cent, cent, vertexCos[(int) efa->v4->tmp.l]);
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
} else {
VECCOPY(cent, efa->v1->co);
VecAddf(cent, cent, efa->v2->co);
VecAddf(cent, cent, efa->v3->co);
if (efa->v4) VecAddf(cent, cent, efa->v4->co);
}
if (efa->v4) {
- got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented with drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-08-07 07:42:03 +02:00
VecMulf(cent, 0.25f);
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
} else {
- got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented with drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-08-07 07:42:03 +02:00
VecMulf(cent, 0.33333333333f);
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
}
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
static void emDM_foreachMappedFaceCenter(DerivedMesh *dm, void (*func)(void *userData, int index, float *co, float *no), void *userData)
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *eve;
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
EditFace *efa;
float cent[3];
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
int i;
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
if (emdm->vertexCos) {
for (i=0,eve=emdm->em->verts.first; eve; eve= eve->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
eve->tmp.l = (long) i++;
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for(i=0,efa= emdm->em->faces.first; efa; i++,efa= efa->next) {
Big commit, had to rework lots of selection stuff so that things worked properly with modifiers. Needs more testing I am sure. No, honestly, I wasn't just cleaning for the hell of it, it was *necessary* (I would never do such a thing). Selection should work completely with cage options of modifiers now. - added DerivedMesh foreach functions to iterate over mapped verts/edges/face centers. These replaced some of the drawing functions and are more general anyway. Special edge drawing functions remain for performance reasons. - removed EditFace xs, ys fields - added general functions to iterate over screen coordinates of mesh/curve/lattice objects - removed all calc_*verts* functions that were used for storing screen coordinates in objects. they were recalc'd on the fly for most situations anyway, so now we just always do that. calc_*verts_ext was one of those calls that did dirty things deep down in the callstack (changing curarea and poking at matrices) - rewrote all vertex level selection routines (circle, lasso, bbox) and closest vertex routines (rightmouse select) to use the new system. This cleaned up the selection code a lot and the structure of selection is much easier to see now. This is good for future work on allowing modifiers to completely override the selection system. It also points out some discrepancies in the way selection is handled that might be nice to resolve (mesh vertex selection has fancy stuff to try to help with selecting overlapping, but it only works w/o bbuf select, and curves/lattices don't have at all). - had to remove ton's code to move Manipulator to cage location, this is not reliable (can come up with a different method if requested) - as it happens BezTriple.s and BPoint.s are basically available to be removed, just need to rewrite editipo code that still does background calc of screen coordinates - MVert.{xs,ys} are still around because they are abused in some places for other info (not sure if this is safe actually, since they are short's and the mvert limit went up). And did I mention this commit is comes out to -305 lines? Well it does.
2005-08-09 10:12:36 +02:00
emDM__calcFaceCent(efa, cent, emdm->vertexCos);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
func(userData, i, cent, emdm->vertexCos?emdm->faceNos[i]:efa->n);
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
}
}
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
static void emDM_drawMappedFaces(DerivedMesh *dm, int (*setDrawOptions)(void *userData, int index, int *drawSmooth_r), void *userData, int useColors)
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 07:58:43 +02:00
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
- added drawMapped{Verts,Edges,Faces}EMSelect calls to DerivedMesh with implementations - updated drawobject selection code to use DerivedMesh (last DispListMesh usage in drawobject.c that needs to be replaced! Woot!) - interface could still be a lot cleaner, mostly calculating indices for the various things to pass to selection color routine is hacky.
2005-03-28 08:46:21 +02:00
EditFace *efa;
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
int i, draw;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
if (emdm->vertexCos) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *eve;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
for (i=0,eve=emdm->em->verts.first; eve; eve= eve->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
eve->tmp.l = (long) i++;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
for (i=0,efa= emdm->em->faces.first; efa; i++,efa= efa->next) {
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 03:12:36 +02:00
int drawSmooth = (efa->flag & ME_SMOOTH);
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
draw = setDrawOptions==NULL ? 1 : setDrawOptions(userData, i, &drawSmooth);
if(draw) {
if (draw==2) { /* enabled with stipple */
glEnable(GL_POLYGON_STIPPLE);
made editmode face copy menu appier with when there is no active face (without options that required an active face) active face drawing didnt always work since it used the last selected element for drawing. moved stipple into glutil.c rather then using 128 bytes in the stack for each stipple draw.
2008-03-26 17:06:25 +01:00
glPolygonStipple(stipple_quarttone);
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
glShadeModel(drawSmooth?GL_SMOOTH:GL_FLAT);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
- Change DerivedMesh.drawSolidFaces setMaterial argument to return boolean value indicating whether faces with that material should be drawn or not.
2005-07-13 22:16:35 +02:00
glBegin(efa->v4?GL_QUADS:GL_TRIANGLES);
- another drawing bugfix, some normals were passed wrong
2005-08-20 20:49:08 +02:00
if (!drawSmooth) {
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
glNormal3fv(emdm->faceNos[i]);
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
glVertex3fv(emdm->vertexCos[(int) efa->v1->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) efa->v2->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) efa->v3->tmp.l]);
if(efa->v4) glVertex3fv(emdm->vertexCos[(int) efa->v4->tmp.l]);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
} else {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
glNormal3fv(emdm->vertexNos[(int) efa->v1->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) efa->v1->tmp.l]);
glNormal3fv(emdm->vertexNos[(int) efa->v2->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) efa->v2->tmp.l]);
glNormal3fv(emdm->vertexNos[(int) efa->v3->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) efa->v3->tmp.l]);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
if(efa->v4) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
glNormal3fv(emdm->vertexNos[(int) efa->v4->tmp.l]);
glVertex3fv(emdm->vertexCos[(int) efa->v4->tmp.l]);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
glEnd();
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
if (draw==2)
glDisable(GL_POLYGON_STIPPLE);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
}
} else {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
for (i=0,efa= emdm->em->faces.first; efa; i++,efa= efa->next) {
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 03:12:36 +02:00
int drawSmooth = (efa->flag & ME_SMOOTH);
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
draw = setDrawOptions==NULL ? 1 : setDrawOptions(userData, i, &drawSmooth);
if(draw) {
if (draw==2) { /* enabled with stipple */
glEnable(GL_POLYGON_STIPPLE);
made editmode face copy menu appier with when there is no active face (without options that required an active face) active face drawing didnt always work since it used the last selected element for drawing. moved stipple into glutil.c rather then using 128 bytes in the stack for each stipple draw.
2008-03-26 17:06:25 +01:00
glPolygonStipple(stipple_quarttone);
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
glShadeModel(drawSmooth?GL_SMOOTH:GL_FLAT);
glBegin(efa->v4?GL_QUADS:GL_TRIANGLES);
- another drawing bugfix, some normals were passed wrong
2005-08-20 20:49:08 +02:00
if (!drawSmooth) {
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
glNormal3fv(efa->n);
glVertex3fv(efa->v1->co);
glVertex3fv(efa->v2->co);
glVertex3fv(efa->v3->co);
if(efa->v4) glVertex3fv(efa->v4->co);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
} else {
glNormal3fv(efa->v1->no);
glVertex3fv(efa->v1->co);
glNormal3fv(efa->v2->no);
glVertex3fv(efa->v2->co);
glNormal3fv(efa->v3->no);
glVertex3fv(efa->v3->co);
if(efa->v4) {
glNormal3fv(efa->v4->no);
glVertex3fv(efa->v4->co);
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
glEnd();
made active vert/edge/face draw properly with modifiers applied and made their theme default white. removed active face draw in Face/UV (which is now paint mask mode) mode.
2007-09-25 05:31:12 +02:00
if (draw==2)
glDisable(GL_POLYGON_STIPPLE);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
}
}
}
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Textured drawing in Edit Mode ============================= - In textured drawmode it now draws the texture, with solid mode lighting. - UVs and vertex colors for subsurf are not computed incremental yet, so editing in textured drawmode then may not be as fast as the other modes. Implementation Notes: - Added textured drawing functions to the editmesh and subsurf derivedmeshes. - Removed some unused, legacy subsurf code that directly used Mesh. - Restructured texture drawing a bit to make it more clear and allow for editmode drawing. (Peach feature request)
2007-08-28 10:53:36 +02:00
static void emDM_drawFacesTex_common(DerivedMesh *dm,
int (*drawParams)(MTFace *tface, MCol *mcol, int matnr),
int (*drawParamsMapped)(void *userData, int index),
void *userData)
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
EditMesh *em= emdm->em;
float (*vertexCos)[3]= emdm->vertexCos;
float (*vertexNos)[3]= emdm->vertexNos;
EditFace *efa;
int i;
make solid faces draw vertex colors in editmode (they used to use only one of the faces colors per face)
2008-03-26 21:17:20 +01:00
/* always use smooth shading even for flat faces, else vertex colors wont interpolate */
glShadeModel(GL_SMOOTH);
Textured drawing in Edit Mode ============================= - In textured drawmode it now draws the texture, with solid mode lighting. - UVs and vertex colors for subsurf are not computed incremental yet, so editing in textured drawmode then may not be as fast as the other modes. Implementation Notes: - Added textured drawing functions to the editmesh and subsurf derivedmeshes. - Removed some unused, legacy subsurf code that directly used Mesh. - Restructured texture drawing a bit to make it more clear and allow for editmode drawing. (Peach feature request)
2007-08-28 10:53:36 +02:00
if (vertexCos) {
EditVert *eve;
for (i=0,eve=em->verts.first; eve; eve= eve->next)
eve->tmp.l = (long) i++;
for (i=0,efa= em->faces.first; efa; i++,efa= efa->next) {
MTFace *tf= CustomData_em_get(&em->fdata, efa->data, CD_MTFACE);
MCol *mcol= CustomData_em_get(&em->fdata, efa->data, CD_MCOL);
unsigned char *cp= NULL;
int drawSmooth= (efa->flag & ME_SMOOTH);
int flag;
if(drawParams)
flag= drawParams(tf, mcol, efa->mat_nr);
else if(drawParamsMapped)
flag= drawParamsMapped(userData, i);
else
flag= 1;
if(flag != 0) { /* flag 0 == the face is hidden or invisible */
made editmode only force smooth shading when vcols are present (as joe suggested) pythons api's image.unpack() was broken
2008-03-27 12:52:58 +01:00
make solid faces draw vertex colors in editmode (they used to use only one of the faces colors per face)
2008-03-26 21:17:20 +01:00
/* we always want smooth here since otherwise vertex colors dont interpolate */
made editmode only force smooth shading when vcols are present (as joe suggested) pythons api's image.unpack() was broken
2008-03-27 12:52:58 +01:00
if (mcol) {
if (flag==1) {
cp= (unsigned char*)mcol;
}
} else {
glShadeModel(drawSmooth?GL_SMOOTH:GL_FLAT);
}
Textured drawing in Edit Mode ============================= - In textured drawmode it now draws the texture, with solid mode lighting. - UVs and vertex colors for subsurf are not computed incremental yet, so editing in textured drawmode then may not be as fast as the other modes. Implementation Notes: - Added textured drawing functions to the editmesh and subsurf derivedmeshes. - Removed some unused, legacy subsurf code that directly used Mesh. - Restructured texture drawing a bit to make it more clear and allow for editmode drawing. (Peach feature request)
2007-08-28 10:53:36 +02:00
glBegin(efa->v4?GL_QUADS:GL_TRIANGLES);
if (!drawSmooth) {
glNormal3fv(emdm->faceNos[i]);
if(tf) glTexCoord2fv(tf->uv[0]);
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
glVertex3fv(vertexCos[(int) efa->v1->tmp.l]);
if(tf) glTexCoord2fv(tf->uv[1]);
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
glVertex3fv(vertexCos[(int) efa->v2->tmp.l]);
if(tf) glTexCoord2fv(tf->uv[2]);
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
glVertex3fv(vertexCos[(int) efa->v3->tmp.l]);
if(efa->v4) {
if(tf) glTexCoord2fv(tf->uv[3]);
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
glVertex3fv(vertexCos[(int) efa->v4->tmp.l]);
}
} else {
if(tf) glTexCoord2fv(tf->uv[0]);
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
glNormal3fv(vertexNos[(int) efa->v1->tmp.l]);
glVertex3fv(vertexCos[(int) efa->v1->tmp.l]);
if(tf) glTexCoord2fv(tf->uv[1]);
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
glNormal3fv(vertexNos[(int) efa->v2->tmp.l]);
glVertex3fv(vertexCos[(int) efa->v2->tmp.l]);
if(tf) glTexCoord2fv(tf->uv[2]);
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
glNormal3fv(vertexNos[(int) efa->v3->tmp.l]);
glVertex3fv(vertexCos[(int) efa->v3->tmp.l]);
if(efa->v4) {
if(tf) glTexCoord2fv(tf->uv[3]);
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
glNormal3fv(vertexNos[(int) efa->v4->tmp.l]);
glVertex3fv(vertexCos[(int) efa->v4->tmp.l]);
}
}
glEnd();
}
}
} else {
for (i=0,efa= em->faces.first; efa; i++,efa= efa->next) {
MTFace *tf= CustomData_em_get(&em->fdata, efa->data, CD_MTFACE);
MCol *mcol= CustomData_em_get(&em->fdata, efa->data, CD_MCOL);
unsigned char *cp= NULL;
int drawSmooth= (efa->flag & ME_SMOOTH);
int flag;
if(drawParams)
flag= drawParams(tf, mcol, efa->mat_nr);
else if(drawParamsMapped)
flag= drawParamsMapped(userData, i);
else
flag= 1;
if(flag != 0) { /* flag 0 == the face is hidden or invisible */
make solid faces draw vertex colors in editmode (they used to use only one of the faces colors per face)
2008-03-26 21:17:20 +01:00
/* we always want smooth here since otherwise vertex colors dont interpolate */
made editmode only force smooth shading when vcols are present (as joe suggested) pythons api's image.unpack() was broken
2008-03-27 12:52:58 +01:00
if (mcol) {
if (flag==1) {
cp= (unsigned char*)mcol;
}
} else {
glShadeModel(drawSmooth?GL_SMOOTH:GL_FLAT);
}
Textured drawing in Edit Mode ============================= - In textured drawmode it now draws the texture, with solid mode lighting. - UVs and vertex colors for subsurf are not computed incremental yet, so editing in textured drawmode then may not be as fast as the other modes. Implementation Notes: - Added textured drawing functions to the editmesh and subsurf derivedmeshes. - Removed some unused, legacy subsurf code that directly used Mesh. - Restructured texture drawing a bit to make it more clear and allow for editmode drawing. (Peach feature request)
2007-08-28 10:53:36 +02:00
glBegin(efa->v4?GL_QUADS:GL_TRIANGLES);
if (!drawSmooth) {
glNormal3fv(efa->n);
if(tf) glTexCoord2fv(tf->uv[0]);
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
glVertex3fv(efa->v1->co);
if(tf) glTexCoord2fv(tf->uv[1]);
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
glVertex3fv(efa->v2->co);
if(tf) glTexCoord2fv(tf->uv[2]);
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
glVertex3fv(efa->v3->co);
if(efa->v4) {
if(tf) glTexCoord2fv(tf->uv[3]);
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
glVertex3fv(efa->v4->co);
}
} else {
if(tf) glTexCoord2fv(tf->uv[0]);
if(cp) glColor3ub(cp[3], cp[2], cp[1]);
glNormal3fv(efa->v1->no);
glVertex3fv(efa->v1->co);
if(tf) glTexCoord2fv(tf->uv[1]);
if(cp) glColor3ub(cp[7], cp[6], cp[5]);
glNormal3fv(efa->v2->no);
glVertex3fv(efa->v2->co);
if(tf) glTexCoord2fv(tf->uv[2]);
if(cp) glColor3ub(cp[11], cp[10], cp[9]);
glNormal3fv(efa->v3->no);
glVertex3fv(efa->v3->co);
if(efa->v4) {
if(tf) glTexCoord2fv(tf->uv[3]);
if(cp) glColor3ub(cp[15], cp[14], cp[13]);
glNormal3fv(efa->v4->no);
glVertex3fv(efa->v4->co);
}
}
glEnd();
}
}
}
}
static void emDM_drawFacesTex(DerivedMesh *dm, int (*setDrawOptions)(MTFace *tface, MCol *mcol, int matnr))
{
emDM_drawFacesTex_common(dm, setDrawOptions, NULL, NULL);
}
static void emDM_drawMappedFacesTex(DerivedMesh *dm, int (*setDrawOptions)(void *userData, int index), void *userData)
{
emDM_drawFacesTex_common(dm, NULL, setDrawOptions, userData);
}
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
static void emDM_getMinMax(DerivedMesh *dm, float min_r[3], float max_r[3])
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
EditVert *eve;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
int i;
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
- added boundbox_set_from_min_max function - fix DerivedMesh.getMinMax implementations to set min & max when there are no vertices - mesh boundbox calc was wrong in some cases, messed up HOMEKEY and localview zooming
2005-07-18 19:33:51 +02:00
if (emdm->em->verts.first) {
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
for (i=0,eve= emdm->em->verts.first; eve; i++,eve= eve->next) {
if (emdm->vertexCos) {
DO_MINMAX(emdm->vertexCos[i], min_r, max_r);
} else {
DO_MINMAX(eve->co, min_r, max_r);
}
- added boundbox_set_from_min_max function - fix DerivedMesh.getMinMax implementations to set min & max when there are no vertices - mesh boundbox calc was wrong in some cases, messed up HOMEKEY and localview zooming
2005-07-18 19:33:51 +02:00
}
} else {
min_r[0] = min_r[1] = min_r[2] = max_r[0] = max_r[1] = max_r[2] = 0.0;
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
}
}
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
static int emDM_getNumVerts(DerivedMesh *dm)
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
return BLI_countlist(&emdm->em->verts);
}
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 03:12:36 +02:00
static int emDM_getNumEdges(DerivedMesh *dm)
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
return BLI_countlist(&emdm->em->edges);
}
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
static int emDM_getNumFaces(DerivedMesh *dm)
{
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
return BLI_countlist(&emdm->em->faces);
}
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 03:12:36 +02:00
void emDM_getVert(DerivedMesh *dm, int index, MVert *vert_r)
{
EditVert *ev = ((EditMeshDerivedMesh *)dm)->em->verts.first;
int i;
for(i = 0; i < index; ++i) ev = ev->next;
VECCOPY(vert_r->co, ev->co);
vert_r->no[0] = ev->no[0] * 32767.0;
vert_r->no[1] = ev->no[1] * 32767.0;
vert_r->no[2] = ev->no[2] * 32767.0;
/* TODO what to do with vert_r->flag and vert_r->mat_nr? */
vert_r->mat_nr = 0;
-> Bevel tools and Bmesh kernel more missed files!
2008-02-23 23:46:55 +01:00
vert_r->bweight = (unsigned char) (ev->bweight*255.0f);
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 03:12:36 +02:00
}
void emDM_getEdge(DerivedMesh *dm, int index, MEdge *edge_r)
{
EditMesh *em = ((EditMeshDerivedMesh *)dm)->em;
EditEdge *ee = em->edges.first;
EditVert *ev, *v1, *v2;
int i;
for(i = 0; i < index; ++i) ee = ee->next;
edge_r->crease = (unsigned char) (ee->crease*255.0f);
-> Bevel tools and Bmesh kernel more missed files!
2008-02-23 23:46:55 +01:00
edge_r->bweight = (unsigned char) (ee->bweight*255.0f);
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 03:12:36 +02:00
/* TODO what to do with edge_r->flag? */
edge_r->flag = ME_EDGEDRAW|ME_EDGERENDER;
if (ee->seam) edge_r->flag |= ME_SEAM;
if (ee->sharp) edge_r->flag |= ME_SHARP;
#if 0
/* this needs setup of f2 field */
if (!ee->f2) edge_r->flag |= ME_LOOSEEDGE;
#endif
/* goddamn, we have to search all verts to find indices */
v1 = ee->v1;
v2 = ee->v2;
for(i = 0, ev = em->verts.first; v1 || v2; i++, ev = ev->next) {
if(ev == v1) {
edge_r->v1 = i;
v1 = NULL;
}
if(ev == v2) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
edge_r->v2 = i;
v2 = NULL;
- added drawFacesTex function to DerivedMesh with implementations - switched drawmesh.c to use new functions - WHEE! This is last such function that has to be written for the time being, and also effectively marks the end of DL_MESH! DispListMesh still hangs around as a kind of interchange format but should also die once DerivedMesh provides more intimate mesh access. DL_MESH (the displist type for DispListMesh) is still used to hold the DispListMesh, but that will die as soon as new subsurf switches to using a bonafide DerivedMesh implementation. There is also one silly usage for the decimator that is easy to kill. - Oh, and I also made potatoe mode draw mesh vertex colors - seemed to be more uniform behavior.
2005-03-29 09:51:00 +02:00
}
}
}
Fix for bug #3802: Display problems with modifiers and uv face select The bug reported here was already fixed some weeks ago, but there were more issues. Modifier display in face select and paint modes was never properly finished. This fixes some small drawing update glitches, and only allows modifiers that preserve a mapping to the original mesh to be applied. Otherwise selection and painting isn't even possible.
2006-03-11 17:13:10 +01:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void emDM_getFace(DerivedMesh *dm, int index, MFace *face_r)
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 05:08:23 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditMesh *em = ((EditMeshDerivedMesh *)dm)->em;
EditFace *ef = em->faces.first;
EditVert *ev, *v1, *v2, *v3, *v4;
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 03:12:36 +02:00
int i;
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i = 0; i < index; ++i) ef = ef->next;
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
face_r->mat_nr = ef->mat_nr;
face_r->flag = ef->flag;
/* goddamn, we have to search all verts to find indices */
v1 = ef->v1;
v2 = ef->v2;
v3 = ef->v3;
v4 = ef->v4;
if(!v4) face_r->v4 = 0;
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i = 0, ev = em->verts.first; v1 || v2 || v3 || v4;
i++, ev = ev->next) {
if(ev == v1) {
face_r->v1 = i;
v1 = NULL;
}
if(ev == v2) {
face_r->v2 = i;
v2 = NULL;
}
if(ev == v3) {
face_r->v3 = i;
v3 = NULL;
}
if(ev == v4) {
face_r->v4 = i;
v4 = NULL;
- added boundbox_set_from_min_max function - fix DerivedMesh.getMinMax implementations to set min & max when there are no vertices - mesh boundbox calc was wrong in some cases, messed up HOMEKEY and localview zooming
2005-07-18 19:33:51 +02:00
}
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
test_index_face(face_r, NULL, 0, ef->v4?4:3);
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
}
- convert mesh_modifier to return deformed verts instead of leaving in a DL_VERTS type displist (and modifying mesh) - removed DL_VERTS displist type (woot woot) - makeDispListMesh now puts deformed verts in object->derivedDeform - switch over other system parts to new deformed vert storage, still kinda hacky and maybe some inconsistencies... will be sorted out soon enough. - moved build_particle_system to makeDispListMesh... this may have adverse side effects, needs to be sorted out with depgraph system
2005-07-17 19:41:03 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void emDM_copyVertArray(DerivedMesh *dm, MVert *vert_r)
- added DerivedMesh.getVertCos function and implementations - added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-18 21:58:23 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditVert *ev = ((EditMeshDerivedMesh *)dm)->em->verts.first;
- added DerivedMesh.getVertCos function and implementations - added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-18 21:58:23 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for( ; ev; ev = ev->next, ++vert_r) {
VECCOPY(vert_r->co, ev->co);
- added DerivedMesh.getVertCos function and implementations - added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-18 21:58:23 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
vert_r->no[0] = ev->no[0] * 32767.0;
vert_r->no[1] = ev->no[1] * 32767.0;
vert_r->no[2] = ev->no[2] * 32767.0;
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
/* TODO what to do with vert_r->flag and vert_r->mat_nr? */
vert_r->mat_nr = 0;
vert_r->flag = 0;
-> Bevel tools and Bmesh kernel more missed files!
2008-02-23 23:46:55 +01:00
vert_r->bweight = (unsigned char) (ev->bweight*255.0f);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
}
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void emDM_copyEdgeArray(DerivedMesh *dm, MEdge *edge_r)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditMesh *em = ((EditMeshDerivedMesh *)dm)->em;
EditEdge *ee = em->edges.first;
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *ev;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
int i;
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 03:12:36 +02:00
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
/* store vertex indices in tmp union */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(ev = em->verts.first, i = 0; ev; ev = ev->next, ++i)
Derived Mesh Bugfix EditMesh MEdge vertex index were doubled incremented, so more or less always wrong (even worse, could read outside of array).
2008-07-07 03:56:47 +02:00
ev->tmp.l = (long) 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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for( ; ee; ee = ee->next, ++edge_r) {
edge_r->crease = (unsigned char) (ee->crease*255.0f);
-> Bevel tools and Bmesh kernel more missed files!
2008-02-23 23:46:55 +01:00
edge_r->bweight = (unsigned char) (ee->bweight*255.0f);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
/* TODO what to do with edge_r->flag? */
edge_r->flag = ME_EDGEDRAW|ME_EDGERENDER;
if (ee->seam) edge_r->flag |= ME_SEAM;
if (ee->sharp) edge_r->flag |= ME_SHARP;
#if 0
/* this needs setup of f2 field */
if (!ee->f2) edge_r->flag |= ME_LOOSEEDGE;
#endif
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
edge_r->v1 = (int)ee->v1->tmp.l;
edge_r->v2 = (int)ee->v2->tmp.l;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
}
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 03:12:36 +02:00
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void emDM_copyFaceArray(DerivedMesh *dm, MFace *face_r)
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditMesh *em = ((EditMeshDerivedMesh *)dm)->em;
EditFace *ef = em->faces.first;
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *ev;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
int i;
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 03:12:36 +02:00
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
/* store vertexes indices in tmp union */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(ev = em->verts.first, i = 0; ev; ev = ev->next, ++i)
New feature: Face Duplicators. Like vertex-duplicator, but now on a face center, rotated according to face edges, and optionally with scale of the face. http://www.blender3d.org/cms/Face_Duplicator.828.0.html Also: bugfix in undo/redo for relinking data to the UI. It was not checking for Library data, accidentally linking non-library data with same names.
2006-11-29 09:57:32 +01:00
ev->tmp.l = (long) 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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for( ; ef; ef = ef->next, ++face_r) {
face_r->mat_nr = ef->mat_nr;
face_r->flag = ef->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 03:12:36 +02:00
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
face_r->v1 = (int)ef->v1->tmp.l;
face_r->v2 = (int)ef->v2->tmp.l;
face_r->v3 = (int)ef->v3->tmp.l;
if(ef->v4) face_r->v4 = (int)ef->v4->tmp.l;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
else face_r->v4 = 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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
test_index_face(face_r, NULL, 0, ef->v4?4: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 03:12:36 +02:00
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
static void emDM_release(DerivedMesh *dm)
- added DerivedMesh convertToDispListMesh function with implementations, this is to ease migration. - updated particles and STL converter to use DerivedMesh interface. This is a bit wasteful at the moment, but these are not key performance areas. Can update once DerivedMesh has accessors for faces and face data.
2005-03-28 00:42:57 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditMeshDerivedMesh *emdm= (EditMeshDerivedMesh*) dm;
- added DerivedMesh convertToDispListMesh function with implementations, this is to ease migration. - updated particles and STL converter to use DerivedMesh interface. This is a bit wasteful at the moment, but these are not key performance areas. Can update once DerivedMesh has accessors for faces and face data.
2005-03-28 00:42:57 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if (DM_release(dm)) {
if (emdm->vertexCos) {
MEM_freeN(emdm->vertexCos);
MEM_freeN(emdm->vertexNos);
MEM_freeN(emdm->faceNos);
}
MEM_freeN(emdm);
- add allowShared argument to DerivedMesh.convertToDispListMesh to allow returned DLM to share data from DerivedMesh (reduces some copying/memory allocation) - added displistmesh_copyShared function to copy a DLM but not duplicate any internal data - changed crease drawing to use DerivedMesh functions... this means varying edge width style of creases had to go, I replaced by using varying color to show crease weight instead. Don't think this is a big loss since the subsurf result gives you a much better indication of the crease weight anyway. - bug fix in mirror modifier, didn't copy edge creases from editmesh correctly
2005-08-07 04:30:29 +02:00
}
- added DerivedMesh convertToDispListMesh function with implementations, this is to ease migration. - updated particles and STL converter to use DerivedMesh interface. This is a bit wasteful at the moment, but these are not key performance areas. Can update once DerivedMesh has accessors for faces and face data.
2005-03-28 00:42:57 +02:00
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
static DerivedMesh *getEditMeshDerivedMesh(EditMesh *em, Object *ob,
float (*vertexCos)[3])
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
{
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditMeshDerivedMesh *emdm = MEM_callocN(sizeof(*emdm), "emdm");
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
DM_init(&emdm->dm, BLI_countlist(&em->verts),
BLI_countlist(&em->edges), BLI_countlist(&em->faces));
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->dm.getMinMax = emDM_getMinMax;
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->dm.getNumVerts = emDM_getNumVerts;
emdm->dm.getNumEdges = emDM_getNumEdges;
emdm->dm.getNumFaces = emDM_getNumFaces;
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->dm.getVert = emDM_getVert;
emdm->dm.getEdge = emDM_getEdge;
emdm->dm.getFace = emDM_getFace;
emdm->dm.copyVertArray = emDM_copyVertArray;
emdm->dm.copyEdgeArray = emDM_copyEdgeArray;
emdm->dm.copyFaceArray = emDM_copyFaceArray;
emdm->dm.foreachMappedVert = emDM_foreachMappedVert;
emdm->dm.foreachMappedEdge = emDM_foreachMappedEdge;
emdm->dm.foreachMappedFaceCenter = emDM_foreachMappedFaceCenter;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->dm.drawEdges = emDM_drawEdges;
emdm->dm.drawMappedEdges = emDM_drawMappedEdges;
emdm->dm.drawMappedEdgesInterp = emDM_drawMappedEdgesInterp;
emdm->dm.drawMappedFaces = emDM_drawMappedFaces;
Textured drawing in Edit Mode ============================= - In textured drawmode it now draws the texture, with solid mode lighting. - UVs and vertex colors for subsurf are not computed incremental yet, so editing in textured drawmode then may not be as fast as the other modes. Implementation Notes: - Added textured drawing functions to the editmesh and subsurf derivedmeshes. - Removed some unused, legacy subsurf code that directly used Mesh. - Restructured texture drawing a bit to make it more clear and allow for editmode drawing. (Peach feature request)
2007-08-28 10:53:36 +02:00
emdm->dm.drawMappedFacesTex = emDM_drawMappedFacesTex;
emdm->dm.drawFacesTex = emDM_drawFacesTex;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->dm.drawUVEdges = emDM_drawUVEdges;
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->dm.release = emDM_release;
emdm->em = em;
emdm->vertexCos = vertexCos;
- added DerivedMesh.getMinMax function (calls DO_MINMAX on all vertices) - static'd boundbox_displist - added getMinMax implementations for all existing DerivedMesh implementations (mesh, editmesh, displistmesh, and ccgsubsurf)
2005-07-17 06:17:33 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(CustomData_has_layer(&em->vdata, CD_MDEFORMVERT)) {
EditVert *eve;
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 03:12:36 +02: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 22:29:09 +01:00
DM_add_vert_layer(&emdm->dm, CD_MDEFORMVERT, CD_CALLOC, NULL);
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 03:12:36 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(eve = em->verts.first, i = 0; eve; eve = eve->next, ++i)
DM_set_vert_data(&emdm->dm, i, CD_MDEFORMVERT,
CustomData_em_get(&em->vdata, eve->data, CD_MDEFORMVERT));
}
- added getNum{Verts,Faces} accessors to DerivedMesh with implementations - updated edit.c to use DerivedMesh interface
2005-03-27 23:27:12 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if(vertexCos) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
EditVert *eve;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
EditFace *efa;
int totface = BLI_countlist(&em->faces);
int i;
- added DerivedMesh.getVertCos function and implementations - added mesh_create_derived_no_deform[_render] - mesh_create_orco now always goes through a DerivedMesh, some redundant copying atm but can be fixed (and orco generation is not a big bottleneck) New feature: TexMesh (texcomesh) works with subsurf now (are you listening rob?)
2005-07-18 21:58:23 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for (i=0,eve=em->verts.first; eve; eve= eve->next)
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
eve->tmp.l = (long) i++;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
emdm->vertexNos = MEM_callocN(sizeof(*emdm->vertexNos)*i, "emdm_vno");
emdm->faceNos = MEM_mallocN(sizeof(*emdm->faceNos)*totface, "emdm_vno");
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i=0, efa= em->faces.first; efa; i++, efa=efa->next) {
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
float *v1 = vertexCos[(int) efa->v1->tmp.l];
float *v2 = vertexCos[(int) efa->v2->tmp.l];
float *v3 = vertexCos[(int) efa->v3->tmp.l];
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
float *no = emdm->faceNos[i];
if(efa->v4) {
Fixed editmode post-modifier normal calculation for the case where there are only deform modifiers in the stack. This was an old bug: a typo caused quad face normals to be calculated using the same vertex twice, giving bad normals.
2007-05-16 19:20:02 +02:00
float *v4 = vertexCos[(int) efa->v4->tmp.l];
- got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented with drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-08-07 07:42:03 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CalcNormFloat4(v1, v2, v3, v4, no);
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
VecAddf(emdm->vertexNos[(int) efa->v4->tmp.l], emdm->vertexNos[(int) efa->v4->tmp.l], 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 05:28:02 +01:00
}
else {
CalcNormFloat(v1, v2, v3, no);
}
- got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented with drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-08-07 07:42:03 +02:00
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
VecAddf(emdm->vertexNos[(int) efa->v1->tmp.l], emdm->vertexNos[(int) efa->v1->tmp.l], no);
VecAddf(emdm->vertexNos[(int) efa->v2->tmp.l], emdm->vertexNos[(int) efa->v2->tmp.l], no);
VecAddf(emdm->vertexNos[(int) efa->v3->tmp.l], emdm->vertexNos[(int) efa->v3->tmp.l], no);
- got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented with drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-08-07 07:42:03 +02:00
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i=0, eve= em->verts.first; eve; i++, eve=eve->next) {
float *no = emdm->vertexNos[i];
/* following Mesh convention; we use vertex coordinate itself
* for normal in this case */
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 15:18:41 +02:00
if (Normalize(no)==0.0) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
VECCOPY(no, vertexCos[i]);
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 15:18:41 +02:00
Normalize(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 05:28:02 +01:00
}
- got rid of DerivedMesh.drawMappedEdgeEM function, can be implemented with drawMappedEdges - added DerivedMesh.convertToDispListMeshMapped function which converts and also returns mapping information for use in editmode - updated DispListMesh derivedmesh to be able to function in editmode - update mirror modifier to support use as a cage - update mirror & subsurf modifiers to properly pass mapping information down modifier stack It is now possible to have a mesh with mirror/subsurf modifiers where you can edit with both as cage. Selecting the mirror'd part works, but of course transform is flipped so it is a bit weird. Not the cleanest code in the world and I can't say I am really happy with the architecture but it works for now and supports the existing feature set.
2005-08-07 07:42:03 +02:00
}
}
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
return (DerivedMesh*) emdm;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#ifdef WITH_VERSE
/* verse derived mesh */
typedef struct {
struct DerivedMesh dm;
struct VNode *vnode;
struct VLayer *vertex_layer;
struct VLayer *polygon_layer;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
struct ListBase *edges;
float (*vertexCos)[3];
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
} VDerivedMesh;
/* this function set up border points of verse mesh bounding box */
static void vDM_getMinMax(DerivedMesh *dm, float min_r[3], float max_r[3])
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert;
if(!vdm->vertex_layer) return;
vvert = (VerseVert*)vdm->vertex_layer->dl.lb.first;
if(vdm->vertex_layer->dl.da.count > 0) {
while(vvert) {
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
DO_MINMAX(vdm->vertexCos ? vvert->cos : vvert->co, min_r, max_r);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vvert = vvert->next;
}
}
else {
min_r[0] = min_r[1] = min_r[2] = max_r[0] = max_r[1] = max_r[2] = 0.0;
}
}
/* this function return number of vertexes in vertex layer */
static int vDM_getNumVerts(DerivedMesh *dm)
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
if(!vdm->vertex_layer) return 0;
else return vdm->vertex_layer->dl.da.count;
}
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
/* this function return number of 'fake' edges */
static int vDM_getNumEdges(DerivedMesh *dm)
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
return BLI_countlist(vdm->edges);
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
/* this function returns number of polygons in polygon layer */
static int vDM_getNumFaces(DerivedMesh *dm)
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
if(!vdm->polygon_layer) return 0;
else return vdm->polygon_layer->dl.da.count;
}
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
/* this function doesn't return vertex with index of access array,
* but it return 'indexth' vertex of dynamic list */
void vDM_getVert(DerivedMesh *dm, int index, MVert *vert_r)
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
int i;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
if(!vdm->vertex_layer) return;
for(vvert = vdm->vertex_layer->dl.lb.first, i=0 ; i<index; i++) vvert = vvert->next;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
if(vvert) {
VECCOPY(vert_r->co, vvert->co);
vert_r->no[0] = vvert->no[0] * 32767.0;
vert_r->no[1] = vvert->no[1] * 32767.0;
vert_r->no[2] = vvert->no[2] * 32767.0;
/* TODO what to do with vert_r->flag and vert_r->mat_nr? */
vert_r->mat_nr = 0;
vert_r->flag = 0;
}
}
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
/* this function returns fake verse edge */
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
void vDM_getEdge(DerivedMesh *dm, int index, MEdge *edge_r)
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseEdge *vedge;
struct VLayer *vert_vlayer = vdm->vertex_layer;
struct VerseVert *vvert;
int j;
if(!vdm->vertex_layer || !vdm->edges) return;
if(vdm->edges->first) {
struct VerseVert *vvert1, *vvert2;
/* store vert indices in tmp union */
for(vvert = vdm->vertex_layer->dl.lb.first, j = 0; vvert; vvert = vvert->next, j++)
vvert->tmp.index = j;
for(vedge = vdm->edges->first; vedge; vedge = vedge->next) {
if(vedge->tmp.index==index) {
vvert1 = BLI_dlist_find_link(&(vert_vlayer->dl), (unsigned int)vedge->v0);
vvert2 = BLI_dlist_find_link(&(vert_vlayer->dl), (unsigned int)vedge->v1);
if(vvert1 && vvert2) {
edge_r->v1 = vvert1->tmp.index;
edge_r->v2 = vvert2->tmp.index;
}
else {
edge_r->v1 = 0;
edge_r->v2 = 0;
}
/* not supported yet */
edge_r->flag = 0;
edge_r->crease = 0;
-> Bevel tools and Bmesh kernel more missed files!
2008-02-23 23:46:55 +01:00
edge_r->bweight = 0;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
break;
}
}
}
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
}
/* this function doesn't return face with index of access array,
* but it returns 'indexth' vertex of dynamic list */
void vDM_getFace(DerivedMesh *dm, int index, MFace *face_r)
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseFace *vface;
struct VerseVert *vvert;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
struct VerseVert *vvert0, *vvert1, *vvert2, *vvert3;
int i;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
if(!vdm->vertex_layer || !vdm->polygon_layer) return;
for(vface = vdm->polygon_layer->dl.lb.first, i = 0; i < index; ++i) vface = vface->next;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
face_r->mat_nr = 0;
face_r->flag = 0;
/* goddamn, we have to search all verts to find indices */
vvert0 = vface->vvert0;
vvert1 = vface->vvert1;
vvert2 = vface->vvert2;
vvert3 = vface->vvert3;
if(!vvert3) face_r->v4 = 0;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
for(vvert = vdm->vertex_layer->dl.lb.first, i = 0; vvert0 || vvert1 || vvert2 || vvert3; i++, vvert = vvert->next) {
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
if(vvert == vvert0) {
face_r->v1 = i;
vvert0 = NULL;
}
if(vvert == vvert1) {
face_r->v2 = i;
vvert1 = NULL;
}
if(vvert == vvert2) {
face_r->v3 = i;
vvert2 = NULL;
}
if(vvert == vvert3) {
face_r->v4 = i;
vvert3 = NULL;
}
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
test_index_face(face_r, NULL, 0, vface->vvert3?4:3);
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
}
/* fill array of mvert */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void vDM_copyVertArray(DerivedMesh *dm, MVert *vert_r)
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert;
if(!vdm->vertex_layer) return;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
for(vvert = vdm->vertex_layer->dl.lb.first ; vvert; vvert = vvert->next, ++vert_r) {
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
VECCOPY(vert_r->co, vvert->co);
vert_r->no[0] = vvert->no[0] * 32767.0;
vert_r->no[1] = vvert->no[1] * 32767.0;
vert_r->no[2] = vvert->no[2] * 32767.0;
vert_r->mat_nr = 0;
vert_r->flag = 0;
}
}
/* dummy function, edges arent supported in verse mesh */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void vDM_copyEdgeArray(DerivedMesh *dm, MEdge *edge_r)
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
if(!vdm->vertex_layer || !vdm->edges) return;
if(vdm->edges->first) {
struct VerseEdge *vedge;
struct VLayer *vert_vlayer = vdm->vertex_layer;
struct VerseVert *vvert, *vvert1, *vvert2;
int j;
/* store vert indices in tmp union */
for(vvert = vdm->vertex_layer->dl.lb.first, j = 0; vvert; vvert = vvert->next, ++j)
vvert->tmp.index = j;
for(vedge = vdm->edges->first, j=0 ; vedge; vedge = vedge->next, ++edge_r, j++) {
/* create temporary edge index */
vedge->tmp.index = j;
vvert1 = BLI_dlist_find_link(&(vert_vlayer->dl), (unsigned int)vedge->v0);
vvert2 = BLI_dlist_find_link(&(vert_vlayer->dl), (unsigned int)vedge->v1);
if(vvert1 && vvert2) {
edge_r->v1 = vvert1->tmp.index;
edge_r->v2 = vvert2->tmp.index;
}
else {
printf("error: vDM_copyEdgeArray: %d, %d\n", vedge->v0, vedge->v1);
edge_r->v1 = 0;
edge_r->v2 = 0;
}
/* not supported yet */
edge_r->flag = 0;
edge_r->crease = 0;
-> Bevel tools and Bmesh kernel more missed files!
2008-02-23 23:46:55 +01:00
edge_r->bweight = 0;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
}
}
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
}
/* fill array of mfaces */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
void vDM_copyFaceArray(DerivedMesh *dm, MFace *face_r)
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
{
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseFace *vface;
struct VerseVert *vvert;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
int i;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
if(!vdm->vertex_layer || !vdm->polygon_layer) return;
- eve->tmp.l is used for storing temporary indexes (not prev pointer) - several for loops were deleted - several warnings were removed
2006-11-22 17:44:27 +01:00
/* store vertexes indices in tmp union */
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
for(vvert = vdm->vertex_layer->dl.lb.first, i = 0; vvert; vvert = vvert->next, ++i)
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
vvert->tmp.index = i;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
for(vface = vdm->polygon_layer->dl.lb.first; vface; vface = vface->next, ++face_r) {
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
face_r->mat_nr = 0;
face_r->flag = 0;
face_r->v1 = vface->vvert0->tmp.index;
face_r->v2 = vface->vvert1->tmp.index;
face_r->v3 = vface->vvert2->tmp.index;
if(vface->vvert3) face_r->v4 = vface->vvert3->tmp.index;
else face_r->v4 = 0;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
test_index_face(face_r, NULL, 0, vface->vvert3?4:3);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
}
}
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
/* return coordination of vertex with index */
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
static void vDM_getVertCo(DerivedMesh *dm, int index, float co_r[3])
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert = NULL;
if(!vdm->vertex_layer) return;
vvert = BLI_dlist_find_link(&(vdm->vertex_layer->dl), index);
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
if(vvert) {
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VECCOPY(co_r, vdm->vertexCos ? vvert->cos : vvert->co);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
}
else {
co_r[0] = co_r[1] = co_r[2] = 0.0;
}
}
/* return array of vertex coordiantions */
static void vDM_getVertCos(DerivedMesh *dm, float (*cos_r)[3])
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert;
int i = 0;
if(!vdm->vertex_layer) return;
vvert = vdm->vertex_layer->dl.lb.first;
while(vvert) {
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
VECCOPY(cos_r[i], vdm->vertexCos ? vvert->cos : vvert->co);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
i++;
vvert = vvert->next;
}
}
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
/* return normal of vertex with index */
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
static void vDM_getVertNo(DerivedMesh *dm, int index, float no_r[3])
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert = NULL;
if(!vdm->vertex_layer) return;
vvert = BLI_dlist_find_link(&(vdm->vertex_layer->dl), index);
if(vvert) {
VECCOPY(no_r, vvert->no);
}
else {
no_r[0] = no_r[1] = no_r[2] = 0.0;
}
}
/* draw all VerseVertexes */
static void vDM_drawVerts(DerivedMesh *dm)
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseVert *vvert;
if(!vdm->vertex_layer) return;
vvert = vdm->vertex_layer->dl.lb.first;
bglBegin(GL_POINTS);
while(vvert) {
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
bglVertex3fv(vdm->vertexCos ? vvert->cos : vvert->co);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vvert = vvert->next;
}
bglEnd();
}
/* draw all edges of VerseFaces ... it isn't optimal, because verse
* specification doesn't support edges :-( ... bother eskil ;-)
* ... some edges (most of edges) are drawn twice */
static void vDM_drawEdges(DerivedMesh *dm, int drawLooseEdges)
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
struct VerseEdge *vedge;
struct VLayer *vert_vlayer = vdm->vertex_layer;
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
if(vert_vlayer && vdm->edges && (BLI_countlist(vdm->edges) > 0)) {
struct VerseVert *vvert1, *vvert2;
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glBegin(GL_LINES);
for(vedge = vdm->edges->first; vedge; vedge = vedge->next) {
vvert1 = BLI_dlist_find_link(&(vert_vlayer->dl), (unsigned int)vedge->v0);
vvert2 = BLI_dlist_find_link(&(vert_vlayer->dl), (unsigned int)vedge->v1);
if(vvert1 && vvert2) {
glVertex3fv(vdm->vertexCos ? vvert1->cos : vvert1->co);
glVertex3fv(vdm->vertexCos ? vvert2->cos : vvert2->co);
}
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
glEnd();
}
}
/* verse spec doesn't support edges ... loose edges can't exist */
void vDM_drawLooseEdges(DerivedMesh *dm)
{
}
/* draw uv edges, not supported yet */
static void vDM_drawUVEdges(DerivedMesh *dm)
{
}
/* draw all VerseFaces */
static void vDM_drawFacesSolid(DerivedMesh *dm, int (*setMaterial)(int))
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseFace *vface;
if(!vdm->polygon_layer) return;
vface = vdm->polygon_layer->dl.lb.first;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glShadeModel(GL_FLAT);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
while(vface) {
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glBegin(vface->vvert3?GL_QUADS:GL_TRIANGLES);
glNormal3fv(vface->no);
glVertex3fv(vdm->vertexCos ? vface->vvert0->cos : vface->vvert0->co);
glVertex3fv(vdm->vertexCos ? vface->vvert1->cos : vface->vvert1->co);
glVertex3fv(vdm->vertexCos ? vface->vvert2->cos : vface->vvert2->co);
if(vface->vvert3)
glVertex3fv(vdm->vertexCos ? vface->vvert3->cos : vface->vvert3->co);
glEnd();
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vface = vface->next;
}
}
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
/* this function should draw mesh with mapped texture, but it isn't supported yet */
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
static void vDM_drawFacesTex(DerivedMesh *dm, int (*setDrawOptions)(MTFace *tface, MCol *mcol, int matnr))
- bug fix, bug reported by Campbel, thanks! Keep in mind, that integration of verse supports only sharing of mesh geometry now, you can't share vertex color, vertex weight, etc.
2006-08-21 15:19:18 +02:00
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseFace *vface;
if(!vdm->polygon_layer) return;
vface = vdm->polygon_layer->dl.lb.first;
while(vface) {
glBegin(vface->vvert3?GL_QUADS:GL_TRIANGLES);
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glVertex3fv(vdm->vertexCos ? vface->vvert0->cos : vface->vvert0->co);
glVertex3fv(vdm->vertexCos ? vface->vvert1->cos : vface->vvert1->co);
glVertex3fv(vdm->vertexCos ? vface->vvert2->cos : vface->vvert2->co);
- bug fix, bug reported by Campbel, thanks! Keep in mind, that integration of verse supports only sharing of mesh geometry now, you can't share vertex color, vertex weight, etc.
2006-08-21 15:19:18 +02:00
if(vface->vvert3)
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glVertex3fv(vdm->vertexCos ? vface->vvert3->cos : vface->vvert3->co);
- bug fix, bug reported by Campbel, thanks! Keep in mind, that integration of verse supports only sharing of mesh geometry now, you can't share vertex color, vertex weight, etc.
2006-08-21 15:19:18 +02:00
glEnd();
vface = vface->next;
}
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
/* this function should draw mesh with colored faces (weight paint, vertex
* colors, etc.), but it isn't supported yet */
static void vDM_drawFacesColored(DerivedMesh *dm, int useTwoSided, unsigned char *col1, unsigned char *col2)
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
struct VerseFace *vface;
if(!vdm->polygon_layer) return;
vface = vdm->polygon_layer->dl.lb.first;
while(vface) {
glBegin(vface->vvert3?GL_QUADS:GL_TRIANGLES);
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glVertex3fv(vdm->vertexCos ? vface->vvert0->cos : vface->vvert0->co);
glVertex3fv(vdm->vertexCos ? vface->vvert1->cos : vface->vvert1->co);
glVertex3fv(vdm->vertexCos ? vface->vvert2->cos : vface->vvert2->co);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
if(vface->vvert3)
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
glVertex3fv(vdm->vertexCos ? vface->vvert3->cos : vface->vvert3->co);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
glEnd();
vface = vface->next;
}
}
/**/
static void vDM_foreachMappedVert(
DerivedMesh *dm,
void (*func)(void *userData, int index, float *co, float *no_f, short *no_s),
void *userData)
{
}
/**/
static void vDM_foreachMappedEdge(
DerivedMesh *dm,
void (*func)(void *userData, int index, float *v0co, float *v1co),
void *userData)
{
}
/**/
static void vDM_foreachMappedFaceCenter(
DerivedMesh *dm,
void (*func)(void *userData, int index, float *cent, float *no),
void *userData)
{
}
/**/
static void vDM_drawMappedFacesTex(
DerivedMesh *dm,
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
int (*setDrawParams)(void *userData, int index),
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
void *userData)
{
}
/**/
static void vDM_drawMappedFaces(
DerivedMesh *dm,
int (*setDrawOptions)(void *userData, int index, int *drawSmooth_r),
void *userData,
int useColors)
{
}
/**/
static void vDM_drawMappedEdges(
DerivedMesh *dm,
int (*setDrawOptions)(void *userData, int index),
void *userData)
{
}
/**/
static void vDM_drawMappedEdgesInterp(
DerivedMesh *dm,
int (*setDrawOptions)(void *userData, int index),
void (*setDrawInterpOptions)(void *userData, int index, float t),
void *userData)
{
}
/* free all DerivedMesh data */
static void vDM_release(DerivedMesh *dm)
{
VDerivedMesh *vdm = (VDerivedMesh*)dm;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
if (DM_release(dm)) {
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
if(vdm->vertexCos) MEM_freeN(vdm->vertexCos);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MEM_freeN(vdm);
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
}
/* create derived mesh from verse mesh ... it is used in object mode, when some other client can
* change shared data and want to see this changes in real time too */
DerivedMesh *derivedmesh_from_versemesh(VNode *vnode, float (*vertexCos)[3])
{
VDerivedMesh *vdm = MEM_callocN(sizeof(*vdm), "vdm");
vdm->vnode = vnode;
vdm->vertex_layer = find_verse_layer_type((VGeomData*)vnode->data, VERTEX_LAYER);
vdm->polygon_layer = find_verse_layer_type((VGeomData*)vnode->data, POLYGON_LAYER);
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
vdm->edges = &((VGeomData*)vnode->data)->edges;
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
/* vertex and polygon layer has to exist */
- bug fix: vertex and polygon layers needn't to exist in some situations
2006-09-05 11:28:46 +02:00
if(vdm->vertex_layer && vdm->polygon_layer)
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
DM_init(&vdm->dm, vdm->vertex_layer->dl.da.count, BLI_countlist(vdm->edges), vdm->polygon_layer->dl.da.count);
- bug fix: vertex and polygon layers needn't to exist in some situations
2006-09-05 11:28:46 +02:00
else
DM_init(&vdm->dm, 0, 0, 0);
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vdm->dm.getMinMax = vDM_getMinMax;
vdm->dm.getNumVerts = vDM_getNumVerts;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
vdm->dm.getNumEdges = vDM_getNumEdges;
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vdm->dm.getNumFaces = vDM_getNumFaces;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
vdm->dm.getVert = vDM_getVert;
vdm->dm.getEdge = vDM_getEdge;
vdm->dm.getFace = vDM_getFace;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
vdm->dm.copyVertArray = vDM_copyVertArray;
vdm->dm.copyEdgeArray = vDM_copyEdgeArray;
vdm->dm.copyFaceArray = vDM_copyFaceArray;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vdm->dm.foreachMappedVert = vDM_foreachMappedVert;
vdm->dm.foreachMappedEdge = vDM_foreachMappedEdge;
vdm->dm.foreachMappedFaceCenter = vDM_foreachMappedFaceCenter;
vdm->dm.getVertCos = vDM_getVertCos;
vdm->dm.getVertCo = vDM_getVertCo;
vdm->dm.getVertNo = vDM_getVertNo;
vdm->dm.drawVerts = vDM_drawVerts;
vdm->dm.drawEdges = vDM_drawEdges;
vdm->dm.drawLooseEdges = vDM_drawLooseEdges;
vdm->dm.drawUVEdges = vDM_drawUVEdges;
vdm->dm.drawFacesSolid = vDM_drawFacesSolid;
- bug fix, bug reported by Campbel, thanks! Keep in mind, that integration of verse supports only sharing of mesh geometry now, you can't share vertex color, vertex weight, etc.
2006-08-21 15:19:18 +02:00
vdm->dm.drawFacesTex = vDM_drawFacesTex;
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
vdm->dm.drawFacesColored = vDM_drawFacesColored;
vdm->dm.drawMappedFacesTex = vDM_drawMappedFacesTex;
vdm->dm.drawMappedFaces = vDM_drawMappedFaces;
vdm->dm.drawMappedEdges = vDM_drawMappedEdges;
vdm->dm.drawMappedEdgesInterp = vDM_drawMappedEdgesInterp;
vdm->dm.release = vDM_release;
- support for fake verse edges (subsurf modifier should work now) - edges are generated from verse faces - no support for lose edge! - informations about edges aren't sent to verse server (other applications can't share edges with blender) - better sending/receiving vertex position
2007-04-27 16:04:30 +02:00
vdm->vertexCos = vertexCos;
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
return (DerivedMesh*) vdm;
}
#endif
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
/***/
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
- added apply button for individual modifiers
2005-07-26 02:45:19 +02:00
DerivedMesh *mesh_create_derived_for_modifier(Object *ob, ModifierData *md)
{
Mesh *me = ob->data;
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- added apply button for individual modifiers
2005-07-26 02:45:19 +02:00
DerivedMesh *dm;
if (!(md->mode&eModifierMode_Realtime)) return NULL;
if (mti->isDisabled && mti->isDisabled(md)) return NULL;
if (mti->type==eModifierTypeType_OnlyDeform) {
int numVerts;
float (*deformedVerts)[3] = mesh_getVertexCos(me, &numVerts);
mti->deformVerts(md, ob, NULL, deformedVerts, numVerts);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#ifdef WITH_VERSE
if(me->vnode) dm = derivedmesh_from_versemesh(me->vnode, deformedVerts);
else dm = getMeshDerivedMesh(me, ob, deformedVerts);
#else
- added apply button for individual modifiers
2005-07-26 02:45:19 +02:00
dm = getMeshDerivedMesh(me, ob, deformedVerts);
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#endif
- added apply button for individual modifiers
2005-07-26 02:45:19 +02:00
MEM_freeN(deformedVerts);
} else {
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 03:12:36 +02:00
DerivedMesh *tdm = getMeshDerivedMesh(me, ob, NULL);
dm = mti->applyModifier(md, ob, tdm, 0, 0);
if(tdm != dm) tdm->release(tdm);
- added apply button for individual modifiers
2005-07-26 02:45:19 +02:00
}
return dm;
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
CustomDataMask get_viewedit_datamask()
{
CustomDataMask mask = CD_MASK_BAREMESH;
ScrArea *sa;
/* check if we need tfaces & mcols due to face select or texture paint */
Changes to "Face Select" mode * Does not indicate that UV's exist, nor does it add UV's when used. * Only accessible for texturepaint, vertexpaint and weightpaint from a button in the header (Paint Selection Mask) * Not accessible from the mode menu, this is only an option that applies to paint modes. This dosnt effect DNA, face select (G_FACESELECT) can be enabled at any time but is only used when paint modes are enabled. Other changes * UKey is uv unwrap in editmode, Ukey for undo was editmode only anyway. * UVCalc in editmode adds a UV Layer if there is not one alredy. * texture draw in editmode does not draw the face dots (they are get in the way of texturing) * some missing updates were added. * removed manipulator from when paint modes are enabled since the manipulator is not drawn in the 3d view.
2007-09-10 21:32:44 +02:00
if(FACESEL_PAINT_TEST || G.f & G_TEXTUREPAINT) {
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mask |= CD_MASK_MTFACE | CD_MASK_MCOL;
} else {
/* check if we need tfaces & mcols due to view mode */
for(sa = G.curscreen->areabase.first; sa; sa = sa->next) {
if(sa->spacetype == SPACE_VIEW3D) {
View3D *view = sa->spacedata.first;
if(view->drawtype == OB_SHADED) {
/* this includes normals for mesh_create_shadedColors */
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
mask |= CD_MASK_MTFACE | CD_MASK_MCOL | CD_MASK_NORMAL | CD_MASK_ORCO;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
}
new view option, SolidTex, to draw textures in solid mode. In the view panel as well as the shortcut Shift+T this works in editmode as well as object mode giving results like this http://members.optusnet.com.au/cjbarton/temp1.jpg where before you could only see textures in textured draw type like this http://members.optusnet.com.au/cjbarton/temp2.jpg
2007-09-15 20:12:16 +02:00
if((view->drawtype == OB_TEXTURE) || ((view->drawtype == OB_SOLID) && (view->flag2 & V3D_SOLID_TEX))) {
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mask |= CD_MASK_MTFACE | CD_MASK_MCOL;
}
}
}
}
/* check if we need mcols due to vertex paint or weightpaint */
if(G.f & G_VERTEXPAINT || G.f & G_WEIGHTPAINT)
mask |= CD_MASK_MCOL;
return mask;
}
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
static DerivedMesh *create_orco_dm(Object *ob, Mesh *me)
{
DerivedMesh *dm;
float (*orco)[3];
dm= CDDM_from_mesh(me, ob);
orco= (float(*)[3])get_mesh_orco_verts(ob);
CDDM_apply_vert_coords(dm, orco);
CDDM_calc_normals(dm);
MEM_freeN(orco);
return dm;
}
static void add_orco_dm(Object *ob, DerivedMesh *dm, DerivedMesh *orcodm)
{
float (*orco)[3], (*layerorco)[3];
int totvert;
totvert= dm->getNumVerts(dm);
if(orcodm) {
orco= MEM_callocN(sizeof(float)*3*totvert, "dm orco");
if(orcodm->getNumVerts(orcodm) == totvert)
orcodm->getVertCos(orcodm, orco);
else
dm->getVertCos(dm, orco);
}
else
orco= (float(*)[3])get_mesh_orco_verts(ob);
Fix for mirroring issues in particle mode, where the particles were not mirrored exactly, though the problem is not completely solved. The way local frames are computed for particles is still not fully symmetric, which shows especially on long hairs... Also made the shift+o subsurf switch work recursively into dupli-groups, did only the first level before.
2007-12-11 21:02:21 +01:00
transform_mesh_orco_verts(ob->data, orco, totvert, 0);
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
if((layerorco = DM_get_vert_data_layer(dm, CD_ORCO))) {
memcpy(layerorco, orco, sizeof(float)*totvert);
MEM_freeN(orco);
}
else
DM_add_vert_layer(dm, CD_ORCO, CD_ASSIGN, orco);
}
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 03:12:36 +02:00
static void mesh_calc_modifiers(Object *ob, float (*inputVertexCos)[3],
DerivedMesh **deform_r, DerivedMesh **final_r,
int useRenderParams, int useDeform,
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
int needMapping, CustomDataMask dataMask)
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
{
- for some reason mesh_create_derived_no_deform took the raw data (not an object) but this is not going to work... I can't remember the reason I did it this way in the first place either! oops! regardless, switch to all mesh_ derived accessors taking object argument. there is still a bug in render orco calculation though. (hunt hunt) - removed python files that should have been ditched in previous commit
2005-07-20 06:44:02 +02:00
Mesh *me = ob->data;
Bugfix: memory leak with multi-modifier, if the modifier using the previous coordinates was disabled.
2007-12-17 12:47:24 +01:00
ModifierData *firstmd, *md;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
LinkNode *datamasks, *curr;
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
CustomDataMask mask;
- added modifiers_getVirtualModifierList, returns pointer to first modifier but including "virtual" modifiers (for example, an object skel-parented to a lattice has a virtual first lattice modifier) - removed mesh_modifier(), all functionality has been incorporated into modifier stack (well, keys still don't exist as a modifier, but I am not sure if they should). - added interface option to convert a virtual modifier into a real modifier - added option to parent to lattice object or lattice with deform - bug fix, patch of hook indices patched all hooks (oops) not just ones for edited mesh NOTE: Files saved with 2.38 that include an object parented to a lattice will not load correctly, because it will look like the object is parented only to the object (i.e. without deform). Can be simply fixed by reparenting or adding a lattice modifier. Older files are handled automatically.
2005-08-11 05:31:33 +02:00
float (*deformedVerts)[3] = NULL;
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
DerivedMesh *dm, *orcodm, *finaldm;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
int numVerts = me->totvert;
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
int fluidsimMeshUsed = 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 03:12:36 +02:00
int required_mode;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
Bugfix: memory leak with multi-modifier, if the modifier using the previous coordinates was disabled.
2007-12-17 12:47:24 +01:00
md = firstmd = modifiers_getVirtualModifierList(ob);
- added eModifierTypeFlag_RequiresOriginalData for modifiers that can only follow deform (for example, they store mesh vertex indices) - added ModifierType.foreachObjectLink for iterating over Object links inside modifier data (used for file load, relinking, etc) - switched various modifiers_ functions to take object argument instead of ListBase - added user editable name field to modifiers - bug fix, duplicate and make single user didn't relink object pointers in modifier data - added modifiers to outliner, needs icon - added armature, hook, and softbody modifiers (softbody doesn't do anything atm). added conversion of old hooks to modifiers. NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files so if you have saved stuff with a cvs blender you will see blank names. NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh objects, hooks for lattices and curves are broken. Don't updated if you actually, say, *use* Blender. NOTE-THE-THIRD: Old hooks used a quirky weighting system during deformation which can't be extended to modifiers. On the upside, I doubt anyone relied on the old quirky system and the new system makes much more sense. (Although the way falloff works is still quite stupid I think).
2005-08-11 00:05:52 +02:00
modifiers_clearErrors(ob);
- modifier UI update (aka, find the modifier buttons!!) - moved back to editing buttons, where life is now cramped... switched to constraint style foldout panes, still a WIP. In particular not sure what buttons should be in header (and if current toggles stay in header if they should also be in an expanded pane). Also need new icons for move up/move down (and drag and drop would of course be nice). Finally current plane is to make it so modifiers will expand out in modifier pane for horizontal orientations instead of just going down down down to goblin town. - added error field to modifiers that is displayed in UI, need to have some way for modifiers to return errors back to interface (esp. important for python) - tweaked cage determination and handling, currently the editmode cage is determined by last modifier with OnCage set that is preceeded completely by modifiers that support mapping or are disabled in editmode. it is kinda confusing, but the interface only lets you toggle OnCage for modifiers that support it - it just might not be clear all the time why you can't toggle a certain modifier OnCage. - update displistmesh_copy to only copy edges if non-NULL There is a display bug that already existed but is more obvious with new modifiers where parts of the pane get drawn in a different area after toggling editmode. It has to do with drawing parts of the interface using GL instead of 100% buttons. I try to keep my grubby little toes out of the interface code so this can wait for Ton to return.
2005-08-04 09:25:43 +02:00
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* we always want to keep original indices */
dataMask |= CD_MASK_ORIGINDEX;
datamasks = modifiers_calcDataMasks(md, dataMask);
curr = datamasks;
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 03:12:36 +02:00
if(deform_r) *deform_r = NULL;
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
*final_r = NULL;
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 03:12:36 +02:00
/* replace original mesh by fluidsim surface mesh for fluidsim
* domain objects
*/
Undo Campbell's last commit that disabled face select mode on fluidsim meshes, and actually fix the bug that caused the crash. The fluidsim result doesn't preserve a mapping to the original mesh, so it shouldn't be displayed in face select mode.
2006-04-07 04:46:20 +02:00
if((G.obedit!=ob) && !needMapping) {
remove old particle system. also removed quat, dquat, and sumohandle from the Object struct since they aren't used anywhere.
2008-04-27 20:26:20 +02:00
if((ob->fluidsimFlag & OB_FLUIDSIM_ENABLE)) {
Undo Campbell's last commit that disabled face select mode on fluidsim meshes, and actually fix the bug that caused the crash. The fluidsim result doesn't preserve a mapping to the original mesh, so it shouldn't be displayed in face select mode.
2006-04-07 04:46:20 +02:00
if(ob->fluidsimSettings->type & OB_FLUIDSIM_DOMAIN) {
loadFluidsimMesh(ob,useRenderParams);
fluidsimMeshUsed = 1;
/* might have changed... */
me = ob->data;
numVerts = me->totvert;
}
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01: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 03:12:36 +02:00
if(useRenderParams) required_mode = eModifierMode_Render;
else required_mode = eModifierMode_Realtime;
if(useDeform) {
if(do_ob_key(ob)) /* shape key makes deform verts */
Cleanup and new features for vertex keys. User doc: http://www.blender3d.org/cms/Shape_Keys.678.0.html - The mixed use of "Vertex Key","Key" or "RVK" in Blender was a bit confusing. Also a 'vertex key' assumes keys per vertex, which actually is only a single key for the entire shape. The discussions on blender.org forums all mentioned "Shape" or "Blend Shapes", which I think is an OK name for a "Vertex Key" in the UI. :) - Most work was code spaghetti cleanup. Doing shape-keys now nicely goes via the depgraph and DerivedMesh. That then allows to have different shapes per object, with the new "Pin" feature. Objects now define what Shape is shown (ob->shapenr) - Added a Shape Panel in the Edit buttons with the various options - Fixed a lot of issues in the IpoWindow, with drawing the channels. For example, deleting a key-line there caused the entire Relative option to go wrong, same for moving the lines up/down. Changing key-line order now reflects in order of channels. The active Shape is drawn more clear now too. - Noticed it doesnt work yet for curves/lattice. Need modifier advise!
2005-09-26 17:34:21 +02:00
deformedVerts = mesh_getVertexCos(me, &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 03:12:36 +02:00
/* Apply all leading deforming modifiers */
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
for(; md; md = md->next, curr = curr->next) {
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +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 03:12:36 +02:00
if((md->mode & required_mode) != required_mode) continue;
if(mti->isDisabled && mti->isDisabled(md)) continue;
if(mti->type == eModifierTypeType_OnlyDeform) {
if(!deformedVerts)
deformedVerts = mesh_getVertexCos(me, &numVerts);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
mti->deformVerts(md, ob, NULL, deformedVerts, numVerts);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
} else {
break;
}
}
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 03:12:36 +02:00
/* Result of all leading deforming modifiers is cached for
* places that wish to use the original mesh but with deformed
* coordinates (vpaint, etc.)
*/
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
if (deform_r) {
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#ifdef WITH_VERSE
if(me->vnode) *deform_r = derivedmesh_from_versemesh(me->vnode, deformedVerts);
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02: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 05:28:02 +01:00
*deform_r = CDDM_from_mesh(me, ob);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
if(deformedVerts) {
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
CDDM_apply_vert_coords(*deform_r, deformedVerts);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
CDDM_calc_normals(*deform_r);
}
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02: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 05:28:02 +01:00
*deform_r = CDDM_from_mesh(me, ob);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
if(deformedVerts) {
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
CDDM_apply_vert_coords(*deform_r, deformedVerts);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
CDDM_calc_normals(*deform_r);
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#endif
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
}
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
} else {
- fixed output behaviour (now behaves just like render output, thus directories in the path are created using RE_make_existing_file in fluidsim.c) - changed default output to be '//fluidsimdata/...' - hopefully fixed bugs #3466 and #3470 (orco texture coords caused problems when the fluidsim mesh was bigger than the original one, one no other deformations were used - new deformedVerts are now allocated in this case in DerivedMesh.c)
2005-12-03 18:45:35 +01:00
if(!fluidsimMeshUsed) {
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 03:12:36 +02:00
/* default behaviour for meshes */
Mesh Deform Modifier ==================== The MeshDeform modifier can deform a mesh with another 'cage' mesh. It is similar to a lattice modifier, but instead of being restricted to the regular grid layout of a lattice, the cage mesh can be modeled to fit the mesh better. http://www.blender.org/development/current-projects/changes-since-244/modifiers/ Implementation Notes: - OpenNL has been refactored a bit to allow least squares matrices to be built without passing the matrix row by row, but instead with random access. MDef doesn't need this actually, but it's using this version of OpenNL so I'm just committing it now. - Mean value weights for polygons have been added to arithb.c, a type of barycentric coordinates for polygons with >= 3 vertices. This might be useful for other parts of blender too.
2007-11-04 23:00:24 +01:00
if(inputVertexCos)
deformedVerts = inputVertexCos;
else
deformedVerts = mesh_getRefKeyCos(me, &numVerts);
- fixed output behaviour (now behaves just like render output, thus directories in the path are created using RE_make_existing_file in fluidsim.c) - changed default output to be '//fluidsimdata/...' - hopefully fixed bugs #3466 and #3470 (orco texture coords caused problems when the fluidsim mesh was bigger than the original one, one no other deformations were used - new deformedVerts are now allocated in this case in DerivedMesh.c)
2005-12-03 18:45:35 +01:00
} else {
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 03:12:36 +02:00
/* the fluid sim mesh might have more vertices than the original
* one, so inputVertexCos shouldnt be used
*/
- fixed output behaviour (now behaves just like render output, thus directories in the path are created using RE_make_existing_file in fluidsim.c) - changed default output to be '//fluidsimdata/...' - hopefully fixed bugs #3466 and #3470 (orco texture coords caused problems when the fluidsim mesh was bigger than the original one, one no other deformations were used - new deformedVerts are now allocated in this case in DerivedMesh.c)
2005-12-03 18:45:35 +01:00
deformedVerts = mesh_getVertexCos(me, &numVerts);
}
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
}
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +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 03:12:36 +02:00
/* Now apply all remaining modifiers. If useDeform is off then skip
* OnlyDeform ones.
*/
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
dm = NULL;
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
orcodm = NULL;
- bug fix: mesh object is created corectly after unsubscribing from geometry node - merged patch from Ben Batt, subsurf modifier still doesn't work ... I will add list of edges to VGeomData structure - added some missing derivedmesh methods after merging of ben's gsoc projects
2006-08-30 12:55:46 +02:00
#ifdef WITH_VERSE
/* hack to make sure modifiers don't try to use mesh data from a verse
* node
*/
if(me->vnode) dm = derivedmesh_from_versemesh(me->vnode, deformedVerts);
#endif
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
for(; md; md = md->next, curr = curr->next) {
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +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 03:12:36 +02:00
if((md->mode & required_mode) != required_mode) continue;
if(mti->type == eModifierTypeType_OnlyDeform && !useDeform) continue;
if((mti->flags & eModifierTypeFlag_RequiresOriginalData) && dm) {
Point Cache Refactoring ======================= Caching and Baking: - The point cache is now cleared on DAG_object_flush_update(), and not cleared for time dependency graph updates. - There is now a Bake button instead of Protect. Also cache start and end frames were added to softbody and particles. - The cloth autoprotect feature was removed. - The Ctrl+B menu now also bakes cloth and particles next to softbody and fluids. Additionally there are now frree bake and free cache menu entries. - The point cache api has been changed. There is now a PTCacheID struct for each point cache type that can be filled and then used to call the point cache functions. - PointCache struct was added to DNA and is automatically allocated for each physics type. - Soft body now supports Bake Editing just like cloth. - Tried to make the systems deal consistently with time ipo's and offsets. Still not sure it all works correct, but too complicated to solve completely now. Library Linking: - Added some more warnings to prevent editing settings on library linked objects. - Linked objects now read from the cache located next to the original library file, and never write to it. This restores old behavior for softbodies. For local simulation the mesh and not the object should be linked. - Dupligroups and proxies can't create local point caches at the moment, how to implement that I'm not sure. We probably need a proxy point cache for that to work (ugh). Physics UI: - Renamed deflection panel to collision for consistency and reorganized the buttons. Also removed some softbody collision buttons from the softbody panel that were duplicated in this panel for cloth. - Tweaked field panel buttons to not jump around when changing options. - Tabbing e.g. Soft Body Collision into the Soft Body panel, it now only shows Collision to make the panel names readable. - I tried to make enabled/disabling physics more consistent, since all three system did things different. Now the two modifier buttons to enable the modifier for the viewport and rendering are also duplicated in the physics panels. Toggling the Soft Body and Cloth buttons now both remove their modifiers. - Fixed modifier error drawing glitch. Particles: - Particles are now recalculated more often than before. Previously it did partial updates based on the changes, but that doesn't work well with DAG_object_flush_update() .. - Fixed memory leak loading keyed particle system. Now keys are not written to file anymore but always created after loading. - Make particle threads work with autothreads. Continue Physics: - The timeline play now has a Continue Physics option in the playback menu, which keeps the simulations going without writing them to the cache. - This doesn't always work that well, some changes are not immediately updated, but this can be improved later. Still it's fun to get a feel for the physics. Todo: - Point cache can get out of sync with and undo and changing a file without saving it. - Change the point cache file format to store a version (so old point cache files can be either converted or at least ignored), and to do correct endian conversion. - Menu item and/or buttons for Ctrl+B. - A system("rm ..") was changed to remove() since the former is very slow for clearing point caches. These system() calls were already giving trouble in a bug in the tracker, but really most use of this system("") should be changed and tested. - The Soft Body Collision and Clot Collision panel titles don't mention there's point cache settings there too, doing that makes them unreadable with the default panel setup.. but may need to make the names longer anyway.
2008-04-10 13:39:20 +02:00
modifier_setError(md, "Modifier requires original data, bad stack position.");
- added eModifierTypeFlag_RequiresOriginalData for modifiers that can only follow deform (for example, they store mesh vertex indices) - added ModifierType.foreachObjectLink for iterating over Object links inside modifier data (used for file load, relinking, etc) - switched various modifiers_ functions to take object argument instead of ListBase - added user editable name field to modifiers - bug fix, duplicate and make single user didn't relink object pointers in modifier data - added modifiers to outliner, needs icon - added armature, hook, and softbody modifiers (softbody doesn't do anything atm). added conversion of old hooks to modifiers. NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files so if you have saved stuff with a cvs blender you will see blank names. NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh objects, hooks for lattices and curves are broken. Don't updated if you actually, say, *use* Blender. NOTE-THE-THIRD: Old hooks used a quirky weighting system during deformation which can't be extended to modifiers. On the upside, I doubt anyone relied on the old quirky system and the new system makes much more sense. (Although the way falloff works is still quite stupid I think).
2005-08-11 00:05:52 +02:00
continue;
}
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 03:12:36 +02:00
if(mti->isDisabled && mti->isDisabled(md)) continue;
if(needMapping && !modifier_supportsMapping(md)) continue;
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
/* add an orco layer if needed by this modifier */
if(dm && mti->requiredDataMask) {
mask = mti->requiredDataMask(md);
if(mask & CD_MASK_ORCO)
add_orco_dm(ob, dm, orcodm);
}
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 03:12:36 +02:00
/* How to apply modifier depends on (a) what we already have as
* a result of previous modifiers (could be a DerivedMesh or just
* deformed vertices) and (b) what type the modifier is.
*/
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +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 03:12:36 +02:00
if(mti->type == eModifierTypeType_OnlyDeform) {
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
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 03:12:36 +02:00
/* No existing verts to deform, need to build them. */
if(!deformedVerts) {
if(dm) {
/* Deforming a derived mesh, read the vertex locations
* out of the mesh and deform them. Once done with this
* run of deformers verts will be written back.
*/
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
numVerts = dm->getNumVerts(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 03:12:36 +02:00
deformedVerts =
MEM_mallocN(sizeof(*deformedVerts) * numVerts, "dfmv");
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
dm->getVertCos(dm, deformedVerts);
} else {
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
deformedVerts = mesh_getVertexCos(me, &numVerts);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
}
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
mti->deformVerts(md, ob, dm, deformedVerts, numVerts);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
} else {
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 03:12:36 +02:00
DerivedMesh *ndm;
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +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 03:12:36 +02:00
/* apply vertex coordinates or build a DerivedMesh as necessary */
if(dm) {
if(deformedVerts) {
DerivedMesh *tdm = CDDM_copy(dm);
dm->release(dm);
dm = tdm;
CDDM_apply_vert_coords(dm, deformedVerts);
CDDM_calc_normals(dm);
}
} 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 05:28:02 +01:00
dm = CDDM_from_mesh(me, ob);
Integration of the Google Summer of Code Modifier Stack Upgrade project. The main features are: * Modifiers can now be in any order in the modifier stack * DerivedMesh now has a standard framework for custom element data to be passed through the stack with mesh data (being copied and interpolated as appropriate), so modifiers can access whatever data they need * The modifier stack code has been refactored and a number of bugs have been removed * The EdgeSplit modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/EdgeSplitModifier * The DerivedMesh modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/DisplaceModifier * The UVProject modifier has been added: http://mediawiki.blender.org/index.php/BlenderDev/UVProjectModifier For more info, see: http://mediawiki.blender.org/index.php/User:Artificer/ModifierStackUpgrade (currently undergoing reorganisation)
2006-08-28 03:12:36 +02:00
if(deformedVerts) {
CDDM_apply_vert_coords(dm, deformedVerts);
CDDM_calc_normals(dm);
}
}
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
/* create an orco derivedmesh in parallel */
mask= (CustomDataMask)curr->link;
if(mask & CD_MASK_ORCO) {
if(!orcodm)
orcodm= create_orco_dm(ob, me);
mask &= ~CD_MASK_ORCO;
DM_set_only_copy(orcodm, mask);
ndm = mti->applyModifier(md, ob, orcodm, useRenderParams, !inputVertexCos);
if(ndm) {
/* if the modifier returned a new dm, release the old one */
if(orcodm && orcodm != ndm) orcodm->release(orcodm);
orcodm = ndm;
}
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* set the DerivedMesh to only copy needed data */
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
DM_set_only_copy(dm, mask);
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
/* add an origspace layer if needed */
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
if(((CustomDataMask)curr->link) & CD_MASK_ORIGSPACE)
if(!CustomData_has_layer(&dm->faceData, CD_ORIGSPACE))
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
DM_add_face_layer(dm, CD_ORIGSPACE, CD_DEFAULT, NULL);
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
ndm = mti->applyModifier(md, ob, dm, useRenderParams, !inputVertexCos);
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 03:12:36 +02:00
if(ndm) {
/* if the modifier returned a new dm, release the old one */
if(dm && dm != ndm) dm->release(dm);
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
- added wave modifier & removed old wave effect - added decimate modifier & removed old decimate interface (currently lacks warning about destroying data, and there needs to be a way for modifiers to return errors back to the interface) - allow applyModifier to return NULL to indicate error - unfortunately new decimate modifier means it does not know exact number of faces in mesh (other modifiers may come before) and so instead interface uses a percentage. if people need exact face count slider then I will have to think of some hack to fit this in. note that it does display the output face count so its possible to tweak the pct to get what you want regardless. - removed python Wave object If you are bored now how much easier it is to implement something like decimate as a modifier. Very few changes to interface, very few entry points.
2005-07-26 04:44:59 +02:00
dm = ndm;
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 03:12:36 +02:00
if(deformedVerts) {
if(deformedVerts != inputVertexCos)
- added wave modifier & removed old wave effect - added decimate modifier & removed old decimate interface (currently lacks warning about destroying data, and there needs to be a way for modifiers to return errors back to the interface) - allow applyModifier to return NULL to indicate error - unfortunately new decimate modifier means it does not know exact number of faces in mesh (other modifiers may come before) and so instead interface uses a percentage. if people need exact face count slider then I will have to think of some hack to fit this in. note that it does display the output face count so its possible to tweak the pct to get what you want regardless. - removed python Wave object If you are bored now how much easier it is to implement something like decimate as a modifier. Very few changes to interface, very few entry points.
2005-07-26 04:44:59 +02:00
MEM_freeN(deformedVerts);
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 03:12:36 +02:00
- added wave modifier & removed old wave effect - added decimate modifier & removed old decimate interface (currently lacks warning about destroying data, and there needs to be a way for modifiers to return errors back to the interface) - allow applyModifier to return NULL to indicate error - unfortunately new decimate modifier means it does not know exact number of faces in mesh (other modifiers may come before) and so instead interface uses a percentage. if people need exact face count slider then I will have to think of some hack to fit this in. note that it does display the output face count so its possible to tweak the pct to get what you want regardless. - removed python Wave object If you are bored now how much easier it is to implement something like decimate as a modifier. Very few changes to interface, very few entry points.
2005-07-26 04:44:59 +02:00
deformedVerts = NULL;
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
}
- added wave modifier & removed old wave effect - added decimate modifier & removed old decimate interface (currently lacks warning about destroying data, and there needs to be a way for modifiers to return errors back to the interface) - allow applyModifier to return NULL to indicate error - unfortunately new decimate modifier means it does not know exact number of faces in mesh (other modifiers may come before) and so instead interface uses a percentage. if people need exact face count slider then I will have to think of some hack to fit this in. note that it does display the output face count so its possible to tweak the pct to get what you want regardless. - removed python Wave object If you are bored now how much easier it is to implement something like decimate as a modifier. Very few changes to interface, very few entry points.
2005-07-26 04:44:59 +02:00
}
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
}
}
Shift+O subdivision switching now also allows to switch particle systems on/off if they exist.
2007-12-17 13:54:39 +01:00
for(md=firstmd; md; md=md->next)
Bugfix: memory leak with multi-modifier, if the modifier using the previous coordinates was disabled.
2007-12-17 12:47:24 +01:00
modifier_freeTemporaryData(md);
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 03:12:36 +02:00
/* Yay, we are done. If we have a DerivedMesh and deformed vertices
* need to apply these back onto the DerivedMesh. If we have no
* DerivedMesh then we need to build one.
*/
if(dm && deformedVerts) {
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
finaldm = CDDM_copy(dm);
- split {curve,lattice,armature}_deform_verts out of mesh_deform - removed mesh_deform (merge into mesh_modifier) - switch python lattice_apply function to use object_apply_deform, this isn't exactly equivalent but the python system shouldn't have been calling that deep into the kernel anyway. New feature: Modifier stack - added Object.modifiers (list of ModifierData elements) - added DNA_modifier_types.h o contains type definition for the file data for the various modifier types - added BKE_modifier.h o contains modifierType_get_info (access to modifier type registry) o structs and defines for runtime modifier usage - updated mesh_calc_modifiers to evaluate modifier stack (note that for the time being it also evaluates the old style modifiers so files should load and work as normal). - add file handling modifier code (todo: don't replicate on object copy) - add modifier stack UI code (lives in object panel) Only real new feature at the moment is that you can apply lattices and curves *after* a subdivision surface which was never possible before. Todo: - DEP graph updating does not work correctly yet, so you generally have to tab cycle to see results. - editmode calculation does not use modifier stack. - bug fixes (there must be a few in there somewhere)
2005-07-19 22:14:17 +02:00
dm->release(dm);
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
CDDM_apply_vert_coords(finaldm, deformedVerts);
CDDM_calc_normals(finaldm);
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 03:12:36 +02:00
} else if(dm) {
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
finaldm = dm;
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
} else {
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#ifdef WITH_VERSE
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
if(me->vnode)
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
finaldm = derivedmesh_from_versemesh(me->vnode, deformedVerts);
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
else {
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
finaldm = CDDM_from_mesh(me, ob);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
if(deformedVerts) {
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
CDDM_apply_vert_coords(finaldm, deformedVerts);
CDDM_calc_normals(finaldm);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
}
My modifier stack commit broke weightpaint display for meshes with TFace data, due to the temporary "Weight-coloured" TFace data being replaced by the original before displaying. This commit fixes that by changing the type of DerivedMesh calculated by mesh_calc_modifiers when no non-deforming modifiers are applied from MeshDerivedMesh (which depends on the original Mesh) to CDDerivedMesh (which doesn't depend on the original Mesh).
2006-08-30 05:05:30 +02:00
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#else
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
finaldm = CDDM_from_mesh(me, ob);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
if(deformedVerts) {
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
CDDM_apply_vert_coords(finaldm, deformedVerts);
CDDM_calc_normals(finaldm);
Two bugfixes. My commit to fix weightpaint display (revision 1.125 of DerivedMesh.c) broke normal recalculation for meshes which have only deform modifiers applied. This commit fixes that by adding calls to CDDM_calc_normals in the appropriate places. The DM_from_template and DM_init functions checked for numVerts > 0 before initialising the DerivedMesh's custom data layers. This was something of a hack intended to allow DerivedMesh creation functions to initialise default function pointers without initialising custom data layers (by passing a 0 for the numVerts parameter). It is unneeded now that DM_init_funcs is present, and causes memory deallocation warnings later on when the number of vertices really is 0, so it has been removed.
2006-09-07 08:44:25 +02:00
}
Huge commit: VERSE - All code is in #ifdef ... #endif - Only make build system is supported and you have to add: export WITH_VERSE=true to user-def.mk file - Blender can share only mesh objects and bitmaps now - More informations can be found at wiki: http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlender http://mediawiki.blender.org/index.php/BlenderDev/VerseIntegrationToBlenderUserDoc I hope, that I didn't forget at anything
2006-08-20 17:22:56 +02:00
#endif
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
/* add an orco layer if needed */
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 15:40:25 +01:00
if(dataMask & CD_MASK_ORCO) {
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
add_orco_dm(ob, finaldm, orcodm);
Misc Render Features ==================== - "From Dupli" option for orco and uv texture coordinates. For dupliverts, duplifaces and dupli particles, this uses the orco and uv at the point on the parent surface. Can for example be used for texturing feathers and leafs. Note that uv only works for duplifaces and particles emitted from faces, these are not defined at vertices. - "Width Fade" option for strand render, to fade out along the width of the strand. Committing this so it can be tested, might be changed or removed even, if it doesn't give nice results.
2008-01-09 15:40:25 +01:00
if(deform_r && *deform_r)
add_orco_dm(ob, *deform_r, NULL);
}
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
*final_r = finaldm;
if(orcodm)
orcodm->release(orcodm);
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 03:12:36 +02:00
if(deformedVerts && deformedVerts != inputVertexCos)
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
MEM_freeN(deformedVerts);
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 03:12:36 +02:00
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
BLI_linklist_free(datamasks, NULL);
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 03:12:36 +02:00
/* restore mesh in any case */
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
if(fluidsimMeshUsed) ob->data = ob->fluidsimSettings->orgMesh;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
o some warning fixes (compare of int to NULL, missing prototype)
2005-10-09 18:57:49 +02:00
static float (*editmesh_getVertexCos(EditMesh *em, int *numVerts_r))[3]
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
{
int i, numVerts = *numVerts_r = BLI_countlist(&em->verts);
float (*cos)[3];
EditVert *eve;
cos = MEM_mallocN(sizeof(*cos)*numVerts, "vertexcos");
for (i=0,eve=em->verts.first; i<numVerts; i++,eve=eve->next) {
VECCOPY(cos[i], eve->co);
}
o another warning fix for msvc
2005-10-09 18:59:10 +02:00
return cos;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
Armature CrazySpace Improvement =============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2007-07-28 23:04:30 +02:00
static int editmesh_modifier_is_enabled(ModifierData *md, DerivedMesh *dm)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
int required_mode = eModifierMode_Realtime | eModifierMode_Editmode;
if((md->mode & required_mode) != required_mode) return 0;
if((mti->flags & eModifierTypeFlag_RequiresOriginalData) && dm) {
Point Cache Refactoring ======================= Caching and Baking: - The point cache is now cleared on DAG_object_flush_update(), and not cleared for time dependency graph updates. - There is now a Bake button instead of Protect. Also cache start and end frames were added to softbody and particles. - The cloth autoprotect feature was removed. - The Ctrl+B menu now also bakes cloth and particles next to softbody and fluids. Additionally there are now frree bake and free cache menu entries. - The point cache api has been changed. There is now a PTCacheID struct for each point cache type that can be filled and then used to call the point cache functions. - PointCache struct was added to DNA and is automatically allocated for each physics type. - Soft body now supports Bake Editing just like cloth. - Tried to make the systems deal consistently with time ipo's and offsets. Still not sure it all works correct, but too complicated to solve completely now. Library Linking: - Added some more warnings to prevent editing settings on library linked objects. - Linked objects now read from the cache located next to the original library file, and never write to it. This restores old behavior for softbodies. For local simulation the mesh and not the object should be linked. - Dupligroups and proxies can't create local point caches at the moment, how to implement that I'm not sure. We probably need a proxy point cache for that to work (ugh). Physics UI: - Renamed deflection panel to collision for consistency and reorganized the buttons. Also removed some softbody collision buttons from the softbody panel that were duplicated in this panel for cloth. - Tweaked field panel buttons to not jump around when changing options. - Tabbing e.g. Soft Body Collision into the Soft Body panel, it now only shows Collision to make the panel names readable. - I tried to make enabled/disabling physics more consistent, since all three system did things different. Now the two modifier buttons to enable the modifier for the viewport and rendering are also duplicated in the physics panels. Toggling the Soft Body and Cloth buttons now both remove their modifiers. - Fixed modifier error drawing glitch. Particles: - Particles are now recalculated more often than before. Previously it did partial updates based on the changes, but that doesn't work well with DAG_object_flush_update() .. - Fixed memory leak loading keyed particle system. Now keys are not written to file anymore but always created after loading. - Make particle threads work with autothreads. Continue Physics: - The timeline play now has a Continue Physics option in the playback menu, which keeps the simulations going without writing them to the cache. - This doesn't always work that well, some changes are not immediately updated, but this can be improved later. Still it's fun to get a feel for the physics. Todo: - Point cache can get out of sync with and undo and changing a file without saving it. - Change the point cache file format to store a version (so old point cache files can be either converted or at least ignored), and to do correct endian conversion. - Menu item and/or buttons for Ctrl+B. - A system("rm ..") was changed to remove() since the former is very slow for clearing point caches. These system() calls were already giving trouble in a bug in the tracker, but really most use of this system("") should be changed and tested. - The Soft Body Collision and Clot Collision panel titles don't mention there's point cache settings there too, doing that makes them unreadable with the default panel setup.. but may need to make the names longer anyway.
2008-04-10 13:39:20 +02:00
modifier_setError(md, "Modifier requires original data, bad stack position.");
Armature CrazySpace Improvement =============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2007-07-28 23:04:30 +02:00
return 0;
}
if(mti->isDisabled && mti->isDisabled(md)) return 0;
if(!(mti->flags & eModifierTypeFlag_SupportsEditmode)) return 0;
if(md->mode & eModifierMode_DisableTemporary) return 0;
return 1;
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
static void editmesh_calc_modifiers(DerivedMesh **cage_r,
DerivedMesh **final_r,
CustomDataMask dataMask)
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
{
Object *ob = G.obedit;
EditMesh *em = G.editMesh;
- modifier UI update (aka, find the modifier buttons!!) - moved back to editing buttons, where life is now cramped... switched to constraint style foldout panes, still a WIP. In particular not sure what buttons should be in header (and if current toggles stay in header if they should also be in an expanded pane). Also need new icons for move up/move down (and drag and drop would of course be nice). Finally current plane is to make it so modifiers will expand out in modifier pane for horizontal orientations instead of just going down down down to goblin town. - added error field to modifiers that is displayed in UI, need to have some way for modifiers to return errors back to interface (esp. important for python) - tweaked cage determination and handling, currently the editmode cage is determined by last modifier with OnCage set that is preceeded completely by modifiers that support mapping or are disabled in editmode. it is kinda confusing, but the interface only lets you toggle OnCage for modifiers that support it - it just might not be clear all the time why you can't toggle a certain modifier OnCage. - update displistmesh_copy to only copy edges if non-NULL There is a display bug that already existed but is more obvious with new modifiers where parts of the pane get drawn in a different area after toggling editmode. It has to do with drawing parts of the interface using GL instead of 100% buttons. I try to keep my grubby little toes out of the interface code so this can wait for Ton to return.
2005-08-04 09:25:43 +02:00
ModifierData *md;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
float (*deformedVerts)[3] = NULL;
DerivedMesh *dm;
Seam Cutting in Faceselect Mode: - Mark Border Seam: mark edges on the border of face selection as seam. - Clear Seam: clears seams in selected faces. Hotkey: Ctrl+E - Alt+RMB Click: mark/clear edge as seam - Alt+Shift+RMB Click: mark/clear seams along the shortest/straightest path from last marked seam. The cost of the path also includes some measure of 'straightness' next to the typical distance to make things work more predicatble and edgeloop friendly. Note that this cuts a path from edge to edge, not vertex to vertex. That gives some nice control over the direction of the seam. Also includes: - Removed old LSCM code. - Fix updates glitches with DerivedMesh/Subsurf drawing in FaceSelect mode. Now there's a drawMappedFacesTex instead of drawFacesTex. - Minimize Stretch menu entry called Limit Stitch. - Removed the lasttface global, was being set before it was used anyway, so might as wel return from a function. - Moved some backbuf sampling code to drawview.c from editmesh, so it can be used by Faceselect and VPaint. - Use BLI_heap in parametrizer.c.
2006-02-08 22:01:00 +01:00
int i, numVerts = 0, cageIndex = modifiers_getCageIndex(ob, NULL);
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
LinkNode *datamasks, *curr;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
- added eModifierTypeFlag_RequiresOriginalData for modifiers that can only follow deform (for example, they store mesh vertex indices) - added ModifierType.foreachObjectLink for iterating over Object links inside modifier data (used for file load, relinking, etc) - switched various modifiers_ functions to take object argument instead of ListBase - added user editable name field to modifiers - bug fix, duplicate and make single user didn't relink object pointers in modifier data - added modifiers to outliner, needs icon - added armature, hook, and softbody modifiers (softbody doesn't do anything atm). added conversion of old hooks to modifiers. NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files so if you have saved stuff with a cvs blender you will see blank names. NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh objects, hooks for lattices and curves are broken. Don't updated if you actually, say, *use* Blender. NOTE-THE-THIRD: Old hooks used a quirky weighting system during deformation which can't be extended to modifiers. On the upside, I doubt anyone relied on the old quirky system and the new system makes much more sense. (Although the way falloff works is still quite stupid I think).
2005-08-11 00:05:52 +02:00
modifiers_clearErrors(ob);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +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 03:12:36 +02:00
if(cage_r && cageIndex == -1) {
*cage_r = getEditMeshDerivedMesh(em, ob, NULL);
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
dm = NULL;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
md = ob->modifiers.first;
/* we always want to keep original indices */
dataMask |= CD_MASK_ORIGINDEX;
datamasks = modifiers_calcDataMasks(md, dataMask);
curr = datamasks;
for(i = 0; md; i++, md = md->next, curr = curr->next) {
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
Armature CrazySpace Improvement =============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2007-07-28 23:04:30 +02:00
if(!editmesh_modifier_is_enabled(md, dm))
- added eModifierTypeFlag_RequiresOriginalData for modifiers that can only follow deform (for example, they store mesh vertex indices) - added ModifierType.foreachObjectLink for iterating over Object links inside modifier data (used for file load, relinking, etc) - switched various modifiers_ functions to take object argument instead of ListBase - added user editable name field to modifiers - bug fix, duplicate and make single user didn't relink object pointers in modifier data - added modifiers to outliner, needs icon - added armature, hook, and softbody modifiers (softbody doesn't do anything atm). added conversion of old hooks to modifiers. NOTE-THE-FIRST: User name field is not initialized on loading 2.38 files so if you have saved stuff with a cvs blender you will see blank names. NOTE-THE-SECOND: Since modifiers aren't evaluated yet for non-Mesh objects, hooks for lattices and curves are broken. Don't updated if you actually, say, *use* Blender. NOTE-THE-THIRD: Old hooks used a quirky weighting system during deformation which can't be extended to modifiers. On the upside, I doubt anyone relied on the old quirky system and the new system makes much more sense. (Although the way falloff works is still quite stupid I think).
2005-08-11 00:05:52 +02:00
continue;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +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 03:12:36 +02:00
/* How to apply modifier depends on (a) what we already have as
* a result of previous modifiers (could be a DerivedMesh or just
* deformed vertices) and (b) what type the modifier is.
*/
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +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 03:12:36 +02:00
if(mti->type == eModifierTypeType_OnlyDeform) {
/* No existing verts to deform, need to build them. */
if(!deformedVerts) {
if(dm) {
/* Deforming a derived mesh, read the vertex locations
* out of the mesh and deform them. Once done with this
* run of deformers verts will be written back.
*/
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
numVerts = dm->getNumVerts(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 03:12:36 +02:00
deformedVerts =
MEM_mallocN(sizeof(*deformedVerts) * numVerts, "dfmv");
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
dm->getVertCos(dm, deformedVerts);
} else {
deformedVerts = editmesh_getVertexCos(em, &numVerts);
}
}
mti->deformVertsEM(md, ob, em, dm, deformedVerts, numVerts);
} else {
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 03:12:36 +02:00
DerivedMesh *ndm;
/* apply vertex coordinates or build a DerivedMesh as necessary */
if(dm) {
if(deformedVerts) {
DerivedMesh *tdm = CDDM_copy(dm);
if(!(cage_r && dm == *cage_r)) dm->release(dm);
dm = tdm;
CDDM_apply_vert_coords(dm, deformedVerts);
CDDM_calc_normals(dm);
} else if(cage_r && dm == *cage_r) {
/* dm may be changed by this modifier, so we need to copy it
*/
dm = CDDM_copy(dm);
}
} else {
dm = CDDM_from_editmesh(em, ob->data);
if(deformedVerts) {
CDDM_apply_vert_coords(dm, deformedVerts);
CDDM_calc_normals(dm);
}
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* set the DerivedMesh to only copy needed data */
DM_set_only_copy(dm, (CustomDataMask)curr->link);
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
if(((CustomDataMask)curr->link) & CD_MASK_ORIGSPACE)
if(!CustomData_has_layer(&dm->faceData, CD_ORIGSPACE))
Particles ========= - Texture orco coordinates for particles are now actual orcos instead of just the vertex positions, which means they are the same under deformations and the same as the ones on the mesh. - Particle distribution now uses these orcos to get consistent distributions independent of deformation. - This required changing the way orco's are computed for meshes. Now instead of generating an orco derivedmesh separately, the derivedmesh is generated alongside the regular one and stored in an orco custom data layer.
2007-12-05 13:40:54 +01:00
DM_add_face_layer(dm, CD_ORIGSPACE, CD_DEFAULT, NULL);
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
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 03:12:36 +02:00
ndm = mti->applyModifierEM(md, ob, em, dm);
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
if (ndm) {
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 03:12:36 +02:00
if(dm && dm != ndm)
dm->release(dm);
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
dm = ndm;
if (deformedVerts) {
MEM_freeN(deformedVerts);
deformedVerts = NULL;
}
}
}
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +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 03:12:36 +02:00
if(cage_r && i == cageIndex) {
if(dm && deformedVerts) {
*cage_r = CDDM_copy(dm);
CDDM_apply_vert_coords(*cage_r, deformedVerts);
} else if(dm) {
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
*cage_r = dm;
} else {
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 03:12:36 +02:00
*cage_r =
getEditMeshDerivedMesh(em, ob,
deformedVerts ? MEM_dupallocN(deformedVerts) : NULL);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
}
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
BLI_linklist_free(datamasks, NULL);
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 03:12:36 +02:00
/* Yay, we are done. If we have a DerivedMesh and deformed vertices need
* to apply these back onto the DerivedMesh. If we have no DerivedMesh
* then we need to build one.
*/
if(dm && deformedVerts) {
*final_r = CDDM_copy(dm);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +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 03:12:36 +02:00
if(!(cage_r && dm == *cage_r)) dm->release(dm);
CDDM_apply_vert_coords(*final_r, deformedVerts);
CDDM_calc_normals(*final_r);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
} else if (dm) {
*final_r = dm;
Fixed the "Enable modifier during editmode" button for the case when there are only deform modifiers in the stack. The code that copied the cage mesh to the final mesh didn't check for vertex coordinates; I have added this check.
2007-05-16 17:19:54 +02:00
} else if (!deformedVerts && cage_r && *cage_r) {
Fix for both cage and final DerivedMeshes being created in editmode even if they are identical, as reported by Campbell on the mailing list. Now uses a single DerivedMesh, saves on memory and drawing time.
2007-01-06 02:01:38 +01:00
*final_r = *cage_r;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
} else {
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 03:12:36 +02:00
*final_r = getEditMeshDerivedMesh(em, ob, deformedVerts);
Bugfix for a memory leak in the modifier stack.
2007-02-03 15:46:30 +01:00
deformedVerts = NULL;
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
Bugfix for a memory leak in the modifier stack.
2007-02-03 15:46:30 +01:00
if(deformedVerts)
MEM_freeN(deformedVerts);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
}
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
/***/
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
/* Something of a hack, at the moment deal with weightpaint
* by tucking into colors during modifier eval, only in
* wpaint mode. Works ok but need to make sure recalc
* happens on enter/exit wpaint.
*/
Animation department feature request: support for vertex groups in Lattices In a quick glance: (temp image) http://www.blender.org/bf/rt.png Main reason is that Lattices are useful a lot for Armature deformation. Lattices just provide much more precise and interesting control. However, with only bone envelopes it's very hard to use. Working with Lattice vertex groups is nearly identical to Mesh: - on CTRL+P 'make parent' you can choose the deform option now - In editmode, the buttons to control vertex groups are available - In outliner you can select vertexgroups too - Deforming Lattices with Armatures has all options as for Mesh now. Note: - No WeightPaint has been added yet. To compensate, the editmode drawing for a Lattice with vertex group shows weight values for the active vertex group. - Lattice editmode doesn't undo/redo weight editing yet. - Softbody for Lattice still uses own vertex weights Implementation notes: - derivedmesh weight_to_rgb() is now exported to drawobject.c - been doing cleanups in code (order of includes, var declarations, etc) - weightpaint button handling now is generic I've checked on Brecht's proposal for Custom Element data; http://mediawiki.blender.org/index.php/BlenderDev/CustomElementData It could have been used, but that would mean the existing code for vertexgroup handling and armature deform couldn't be re-used. I guess this is really a later todo.
2006-09-03 14:16:14 +02:00
void weight_to_rgb(float input, float *fr, float *fg, float *fb)
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
{
float blend;
blend= ((input/2.0f)+0.5f);
if (input<=0.25f){ // blue->cyan
*fr= 0.0f;
*fg= blend*input*4.0f;
*fb= blend;
}
else if (input<=0.50f){ // cyan->green
*fr= 0.0f;
*fg= blend;
*fb= blend*(1.0f-((input-0.25f)*4.0f));
}
else if (input<=0.75){ // green->yellow
*fr= blend * ((input-0.50f)*4.0f);
*fg= blend;
*fb= 0.0f;
}
else if (input<=1.0){ // yellow->red
*fr= blend;
*fg= blend * (1.0f-((input-0.75f)*4.0f));
*fb= 0.0f;
}
}
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
static void calc_weightpaint_vert_color(Object *ob, ColorBand *coba, int vert, unsigned char *col)
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
{
Mesh *me = ob->data;
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
float colf[4], input = 0.0f;
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
int i;
if (me->dvert) {
for (i=0; i<me->dvert[vert].totweight; i++)
if (me->dvert[vert].dw[i].def_nr==ob->actdef-1)
input+=me->dvert[vert].dw[i].weight;
}
CLAMP(input, 0.0f, 1.0f);
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
if(coba)
do_colorband(coba, input, colf);
else
weight_to_rgb(input, colf, colf+1, colf+2);
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
col[3] = (unsigned char)(colf[0] * 255.0f);
col[2] = (unsigned char)(colf[1] * 255.0f);
col[1] = (unsigned char)(colf[2] * 255.0f);
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
col[0] = 255;
}
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
static ColorBand *stored_cb= NULL;
void vDM_ColorBand_store(ColorBand *coba)
{
stored_cb= coba;
}
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
static unsigned char *calc_weightpaint_colors(Object *ob)
{
Mesh *me = ob->data;
MFace *mf = me->mface;
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
ColorBand *coba= stored_cb; /* warning, not a local var */
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
unsigned char *wtcol;
int i;
wtcol = MEM_callocN (sizeof (unsigned char) * me->totface*4*4, "weightmap");
memset(wtcol, 0x55, sizeof (unsigned char) * me->totface*4*4);
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
for (i=0; i<me->totface; i++, mf++) {
calc_weightpaint_vert_color(ob, coba, mf->v1, &wtcol[(i*4 + 0)*4]);
calc_weightpaint_vert_color(ob, coba, mf->v2, &wtcol[(i*4 + 1)*4]);
calc_weightpaint_vert_color(ob, coba, mf->v3, &wtcol[(i*4 + 2)*4]);
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
if (mf->v4)
New feature: Weightpaint drawing now allows to define your own range of colors; using a ColorBand, available in the User settings. Log: http://www.blender.org/development/current-projects/changes-since-244/animation-features/
2007-10-31 14:56:07 +01:00
calc_weightpaint_vert_color(ob, coba, mf->v4, &wtcol[(i*4 + 3)*4]);
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
}
return wtcol;
}
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
static void clear_mesh_caches(Object *ob)
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
{
Mesh *me= ob->data;
/* also serves as signal to remake texspace */
Bugfix for mysteriously disappearing left eyeball. Bounding boxes used for clipping were being stored in the mesh, but modifiers can result in two objects with the same mesh having a different bounding box. Solution is to store bounding box in the object.
2007-12-05 22:50:23 +01:00
if (ob->bb) {
MEM_freeN(ob->bb);
ob->bb = NULL;
}
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
if (me->bb) {
MEM_freeN(me->bb);
me->bb = NULL;
}
freedisplist(&ob->disp);
if (ob->derivedFinal) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
ob->derivedFinal->needsFree = 1;
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
ob->derivedFinal->release(ob->derivedFinal);
ob->derivedFinal= NULL;
}
if (ob->derivedDeform) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
ob->derivedDeform->needsFree = 1;
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
ob->derivedDeform->release(ob->derivedDeform);
ob->derivedDeform= NULL;
}
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
}
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
static void mesh_build_data(Object *ob, CustomDataMask dataMask)
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
{
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
Mesh *me = ob->data;
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
float min[3], max[3];
clear_mesh_caches(ob);
- bug fix #2940, at some point assumption that mesh_get_derived_... returned NULL in editmode was invalidated which caused a crash in particles (was freeing subsurf cache). I can't remember but hope that I didn't intentionally break this assumption for some reason. :/
2005-10-09 20:38:40 +02:00
if(ob!=G.obedit) {
Fix for bug #3802: Display problems with modifiers and uv face select The bug reported here was already fixed some weeks ago, but there were more issues. Modifier display in face select and paint modes was never properly finished. This fixes some small drawing update glitches, and only allows modifiers that preserve a mapping to the original mesh to be applied. Otherwise selection and painting isn't even possible.
2006-03-11 17:13:10 +01:00
Object *obact = G.scene->basact?G.scene->basact->object:NULL;
Particles ========= Merge of the famous particle patch by Janne Karhu, a full rewrite of the Blender particle system. This includes: - Emitter, Hair and Reactor particle types. - Newtonian, Keyed and Boids physics. - Various particle visualisation and rendering types. - Vertex group and texture control for various properties. - Interpolated child particles from parents. - Hair editing with combing, growing, cutting, .. . - Explode modifier. - Harmonic, Magnetic fields, and multiple falloff types. .. and lots of other things, some more info is here: http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite http://wiki.blender.org/index.php/BlenderDev/Particles_Rewrite_Doc The new particle system cannot be backwards compatible. Old particle systems are being converted to the new system, but will require tweaking to get them looking the same as before. Point Cache =========== The new system to replace manual baking, based on automatic caching on disk. This is currently used by softbodies and the particle system. See the Cache API section on: http://wiki.blender.org/index.php/BlenderDev/PhysicsSprint Documentation ============= These new features still need good docs for the release logs, help for this is appreciated.
2007-11-26 23:09:57 +01:00
int editing = (FACESEL_PAINT_TEST)|(G.f & G_PARTICLEEDIT);
Fix for bug #3802: Display problems with modifiers and uv face select The bug reported here was already fixed some weeks ago, but there were more issues. Modifier display in face select and paint modes was never properly finished. This fixes some small drawing update glitches, and only allows modifiers that preserve a mapping to the original mesh to be applied. Otherwise selection and painting isn't even possible.
2006-03-11 17:13:10 +01:00
int needMapping = editing && (ob==obact);
if( (G.f & G_WEIGHTPAINT) && ob==obact ) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MCol *wpcol = (MCol*)calc_weightpaint_colors(ob);
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 22:29:09 +01:00
int layernum = CustomData_number_of_layers(&me->fdata, CD_MCOL);
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02: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 22:29:09 +01:00
/* ugly hack here, we temporarily add a new active mcol layer with
weightpaint colors in it, that is then duplicated in CDDM_from_mesh */
CustomData_add_layer(&me->fdata, CD_MCOL, CD_ASSIGN, wpcol, me->totface);
CustomData_set_layer_active(&me->fdata, CD_MCOL, layernum);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mesh_calc_modifiers(ob, NULL, &ob->derivedDeform,
&ob->derivedFinal, 0, 1,
needMapping, dataMask);
- add option to drawMappedFaces to draw with colors (from tface or mcol) - convert weightpaint/vertexpaint to draw using drawMappedFaces, slightly hacky because during weightpaint mcol's get overridden in order to have them propogate through modifiers. should work fine. - add NULL check in shaded draw, prevents crash w/ dupliframe
2005-08-23 22:04:10 +02:00
Select Grouped editdata- minor fix in the menu. Updated Python Mesh API to support UV and Color layers with names. Similar to vertex group's renamed a function in customdata.c CustomData_free_layers -> CustomData_free_layers_active and made CustomData_free_layers accept an index, this is needed so python could free layers that arnt active.
2006-12-23 18:07:02 +01:00
CustomData_free_layer_active(&me->fdata, CD_MCOL, me->totface);
- bug fix #2940, at some point assumption that mesh_get_derived_... returned NULL in editmode was invalidated which caused a crash in particles (was freeing subsurf cache). I can't remember but hope that I didn't intentionally break this assumption for some reason. :/
2005-10-09 20:38:40 +02:00
} else {
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 03:12:36 +02:00
mesh_calc_modifiers(ob, NULL, &ob->derivedDeform,
object in dupli instances were not getting modifiers applied with render settings
2008-01-28 21:45:28 +01:00
&ob->derivedFinal, G.rendering, 1,
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
needMapping, dataMask);
- bug fix #2940, at some point assumption that mesh_get_derived_... returned NULL in editmode was invalidated which caused a crash in particles (was freeing subsurf cache). I can't remember but hope that I didn't intentionally break this assumption for some reason. :/
2005-10-09 20:38:40 +02:00
}
- added DerivedMesh.drawMapped{VertNormals,FaceNormals,FaceCenters}EM functions and implementation for EditmeshDerivedMesh - switch drawobject to drawing normals/centers through the DerivedMesh - added G_DRAW_VNORMALS flag and button, implementation is not yet complete because editmesh normals are not updated regularly - switch editmesh draw buttons to use uiDefButBit (can't we get some monkey to convert all of the uiDefBut calls with TOG|BIT type? It makes grepping the source much nicer)
2005-07-23 09:45:39 +02:00
- bug fix #2940, at some point assumption that mesh_get_derived_... returned NULL in editmode was invalidated which caused a crash in particles (was freeing subsurf cache). I can't remember but hope that I didn't intentionally break this assumption for some reason. :/
2005-10-09 20:38:40 +02:00
INIT_MINMAX(min, max);
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
- bug fix #2940, at some point assumption that mesh_get_derived_... returned NULL in editmode was invalidated which caused a crash in particles (was freeing subsurf cache). I can't remember but hope that I didn't intentionally break this assumption for some reason. :/
2005-10-09 20:38:40 +02:00
ob->derivedFinal->getMinMax(ob->derivedFinal, min, max);
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
Bugfix for mysteriously disappearing left eyeball. Bounding boxes used for clipping were being stored in the mesh, but modifiers can result in two objects with the same mesh having a different bounding box. Solution is to store bounding box in the object.
2007-12-05 22:50:23 +01:00
if(!ob->bb)
Particles ========= - Normalize strand coordinates over the length of the strand, not cut off when with e.g. length texture control. - Weight paint and particle mode x-mirror now works with deformation and shape keys active. - X-ray is now disabled in particle mode, messed up depth tests.
2007-12-06 18:43:47 +01:00
ob->bb= MEM_callocN(sizeof(BoundBox), "bb");
Bugfix for mysteriously disappearing left eyeball. Bounding boxes used for clipping were being stored in the mesh, but modifiers can result in two objects with the same mesh having a different bounding box. Solution is to store bounding box in the object.
2007-12-05 22:50:23 +01:00
boundbox_set_from_min_max(ob->bb, min, max);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
ob->derivedFinal->needsFree = 0;
ob->derivedDeform->needsFree = 0;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
ob->lastDataMask = dataMask;
- bug fix #2940, at some point assumption that mesh_get_derived_... returned NULL in editmode was invalidated which caused a crash in particles (was freeing subsurf cache). I can't remember but hope that I didn't intentionally break this assumption for some reason. :/
2005-10-09 20:38:40 +02:00
}
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
static void editmesh_build_data(CustomDataMask dataMask)
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
{
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
float min[3], max[3];
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
EditMesh *em = G.editMesh;
clear_mesh_caches(G.obedit);
if (em->derivedFinal) {
if (em->derivedFinal!=em->derivedCage) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
em->derivedFinal->needsFree = 1;
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
em->derivedFinal->release(em->derivedFinal);
}
em->derivedFinal = NULL;
}
if (em->derivedCage) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
em->derivedCage->needsFree = 1;
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
em->derivedCage->release(em->derivedCage);
em->derivedCage = NULL;
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
editmesh_calc_modifiers(&em->derivedCage, &em->derivedFinal, dataMask);
em->lastDataMask = dataMask;
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
- change modifier applyModifier[EM] function to not free derived argument - added modifier_supportsMapping function - update CCG to set actual vertex normal (and not just interior face vertex normal, bla bla bla no one knows what this means nevermind). - renamed modifierType_get_info to modifierType_getInfo for consistency and to increase my commit line count. - update EditMeshDerivedMesh to calculate (and use new) normals when given deformed vertices - added - update editmode modifier calculation to also calculate a cage, not working 100% atm, in particular if a deformer follows a modifier that returns a DerivedMesh the cage is not accurate. - added ccg derivedmesh drawMapped{Vert,Face]NormalsEM functions - currently UI for selecting the cage mesh is rather irritating, will be updated
2005-08-03 06:04:05 +02:00
INIT_MINMAX(min, max);
- added data arguments to deformer modifiers, in case someone wants to write one that is based on geometry (and not just vertex position) - added editmode versions of modifier deform/apply calls and flag to tag modifiers that support editmode - added isFinalCalc param to applyModifier, basically a switch to let subsurf know if it is calc'ng orco or not (so it can deal with cache appropriately). This is kinda hacky and perhaps I can come up with a better solution (its also a waste to do a complete subdivide just to get vertex locations). - changed ccgsubsurf to not preallocate hash's to be approximately correct size... this was probably not a big performance savings but means that the order of faces returned by the iterator can vary after the first call, this messes up orco calculation so dropped for time being. - minor bug fix, meshes with only key didn't get vertex normals correctly calc'd - updated editmesh derivedmesh to support auxiliary locations - changed mesh_calc_modifiers to alloc deformVerts on demand - added editmesh_calc_modifiers for calculating editmesh cage and final derivedmesh's - bug fix, update shadedisplist to always calc colors (even if totvert==0) - changed load_editMesh and make_edge to build me->medge even if totedge==0 (incremental subsurf checks this) todo: add drawFacesTex for ccgderivedmesh So, modifiers in editmode are back (which means auto-mirror in edit mode works now) although still not finished. Currently no cage is computed, the cage is always the base mesh (in other words, Optimal edge style editing is off), and the final mesh currently includes all modifiers that work in edit mode (including lattice and curve). At some point there will be toggles for which modifiers affect the final/cage editmode derivedmesh's. Also, very nice new feature is that incremental subsurf in object mode returns a ccgderivedmesh object instead of copying to a new displistmesh. This can make a *huge* speed difference, and is very nice for working with deformed armatures (esp. with only small per frame changes).
2005-07-22 09:37:15 +02:00
em->derivedFinal->getMinMax(em->derivedFinal, min, max);
Bugfix for mysteriously disappearing left eyeball. Bounding boxes used for clipping were being stored in the mesh, but modifiers can result in two objects with the same mesh having a different bounding box. Solution is to store bounding box in the object.
2007-12-05 22:50:23 +01:00
if(!G.obedit->bb)
Particles ========= - Normalize strand coordinates over the length of the strand, not cut off when with e.g. length texture control. - Weight paint and particle mode x-mirror now works with deformation and shape keys active. - X-ray is now disabled in particle mode, messed up depth tests.
2007-12-06 18:43:47 +01:00
G.obedit->bb= MEM_callocN(sizeof(BoundBox), "bb");
Bugfix for mysteriously disappearing left eyeball. Bounding boxes used for clipping were being stored in the mesh, but modifiers can result in two objects with the same mesh having a different bounding box. Solution is to store bounding box in the object.
2007-12-05 22:50:23 +01:00
boundbox_set_from_min_max(G.obedit->bb, min, max);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
em->derivedFinal->needsFree = 0;
em->derivedCage->needsFree = 0;
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
void makeDerivedMesh(Object *ob, CustomDataMask dataMask)
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
{
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
if (ob==G.obedit) {
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
editmesh_build_data(dataMask);
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
} else {
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mesh_build_data(ob, dataMask);
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
}
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
}
/***/
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *mesh_get_derived_final(Object *ob, CustomDataMask dataMask)
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
{
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* if there's no derived mesh or the last data mask used doesn't include
* the data we need, rebuild the derived mesh
*/
if(!ob->derivedFinal || (dataMask & ob->lastDataMask) != dataMask)
mesh_build_data(ob, dataMask);
- Change DerivedMesh.drawSolidFaces setMaterial argument to return boolean value indicating whether faces with that material should be drawn or not.
2005-07-13 22:16:35 +02:00
- split mesh_deform off from object_deform - changed mesh_modifier, sbObjectStep, object_deform to take vertexCo argument instead of operating on mesh - fixed bug where a derived mesh would not be returned in editmode - removed object_wave, replaced by init_wave_deform and calc_wave_deform - moved cached DerivedMesh to Object, not Mesh... fixes heisenbugs with linked objects
2005-07-19 04:36:21 +02:00
return ob->derivedFinal;
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *mesh_get_derived_deform(Object *ob, CustomDataMask dataMask)
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
{
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* if there's no derived mesh or the last data mask used doesn't include
* the data we need, rebuild the derived mesh
*/
if(!ob->derivedDeform || (dataMask & ob->lastDataMask) != dataMask)
mesh_build_data(ob, dataMask);
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
return ob->derivedDeform;
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
}
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
/* Move to multires Pin level, returns a copy of the original vertex coords. */
float *multires_render_pin(Object *ob, Mesh *me, int *orig_lvl)
- added dontFreeVerts and dontFreeOther flags to displistmesh for situations where data can be shared easily. - added convertDisplistToMesh function for regular mesh DerivedMesh interface (how many times can *you* use mesh in one sentence?) - do_puno was uninitialized in init_render_mesh - added mesh_get_derived_final (temporary), difference from mesh_get_derived is it always returns a derived mesh, even if no subsurf.
2005-07-16 23:03:28 +02:00
{
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
float *vert_copy= NULL;
Merged Google Summer of Code sculptmode/multires/retopo tools. From the tracker: https://projects.blender.org/tracker/index.php?func=detail&aid=5018&group_id=9&atid=127
2006-11-06 02:08:26 +01:00
== Multires == Fixed bug #8215, Crash with shaded view + multires mesh
2008-02-09 21:50:25 +01:00
if(me->mr && !(me->mr->flag & MULTIRES_NO_RENDER)) {
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
MultiresLevel *lvl= NULL;
int i;
== Multires == Fixed bug #5799, Multires mesh modifications get reset by rendering This bug can cause some nasty data loss (was introduces with my commit for using orco with multires.) Fixed by making sure to do multires_update_levels before applying modifiers.
2007-01-24 02:34:05 +01:00
/* Make sure all mesh edits are properly stored in the multires data*/
== Multires == Fixed bug #6153, Blender Crash during rendering (internal) with object selected in edit mode. * Added a render parameter to several of multires's functions. If render==true, multires won't push data onto the undo stack, and regular Mesh data is always used (as opposed to EditMesh data.)
2007-03-08 06:54:39 +01:00
multires_update_levels(me, 1);
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
/* Copy the highest level of multires verts */
*orig_lvl= me->mr->current;
lvl= multires_level_n(me->mr, BLI_countlist(&me->mr->levels));
vert_copy= MEM_callocN(sizeof(float)*3*lvl->totvert, "multires vert_copy");
for(i=0; i<lvl->totvert; ++i)
== Multires == * Moved the multires vertex data from struct MultiresLevel to struct Multires. There's no longer any reason to store data seperately for each level; it was just taking up extra memory. * Incremented the subversion to 2 and adjusted do_versions to correctly load older files. * Refactored the multires update process (which handles propagating changes to other levels)
2007-06-01 04:21:11 +02:00
VecCopyf(&vert_copy[i*3], me->mr->verts[i].co);
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
/* Goto the pin level for multires */
me->mr->newlvl= me->mr->pinlvl;
== Multires == Fixed bug #6153, Blender Crash during rendering (internal) with object selected in edit mode. * Added a render parameter to several of multires's functions. If render==true, multires won't push data onto the undo stack, and regular Mesh data is always used (as opposed to EditMesh data.)
2007-03-08 06:54:39 +01:00
multires_set_level(ob, me, 1);
Merged Google Summer of Code sculptmode/multires/retopo tools. From the tracker: https://projects.blender.org/tracker/index.php?func=detail&aid=5018&group_id=9&atid=127
2006-11-06 02:08:26 +01:00
}
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
return vert_copy;
}
- added dontFreeVerts and dontFreeOther flags to displistmesh for situations where data can be shared easily. - added convertDisplistToMesh function for regular mesh DerivedMesh interface (how many times can *you* use mesh in one sentence?) - do_puno was uninitialized in init_render_mesh - added mesh_get_derived_final (temporary), difference from mesh_get_derived is it always returns a derived mesh, even if no subsurf.
2005-07-16 23:03:28 +02:00
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
/* Propagate the changes to render level - fails if mesh topology changed */
Fixed bug #7981, Crash with multires Caused by incorrect handling of multires with orco mapping
2007-12-23 04:03:54 +01:00
void multires_render_final(Object *ob, Mesh *me, DerivedMesh **dm, float *vert_copy,
const int orig_lvl, CustomDataMask dataMask)
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
{
== Multires == Fixed bug #8215, Crash with shaded view + multires mesh
2008-02-09 21:50:25 +01:00
if(me->mr && !(me->mr->flag & MULTIRES_NO_RENDER)) {
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
if((*dm)->getNumVerts(*dm) == me->totvert &&
(*dm)->getNumFaces(*dm) == me->totface) {
MultiresLevel *lvl= multires_level_n(me->mr, BLI_countlist(&me->mr->levels));
DerivedMesh *old= NULL;
== Multires == Fixed bug #8215, Crash with shaded view + multires mesh
2008-02-09 21:50:25 +01:00
MVert *vertdup= NULL;
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
int i;
- added dontFreeVerts and dontFreeOther flags to displistmesh for situations where data can be shared easily. - added convertDisplistToMesh function for regular mesh DerivedMesh interface (how many times can *you* use mesh in one sentence?) - do_puno was uninitialized in init_render_mesh - added mesh_get_derived_final (temporary), difference from mesh_get_derived is it always returns a derived mesh, even if no subsurf.
2005-07-16 23:03:28 +02:00
== Multires == Fixed bug #8215, Crash with shaded view + multires mesh
2008-02-09 21:50:25 +01:00
/* Copy the verts into the mesh */
vertdup= (*dm)->dupVertArray(*dm);
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
(*dm)->release(*dm);
== Multires == Fixed bug #8215, Crash with shaded view + multires mesh
2008-02-09 21:50:25 +01:00
for(i=0; i<me->totvert; ++i)
me->mvert[i]= vertdup[i];
BUGFIX8847 Multires didn't free some memory.fixed
2008-04-02 05:17:52 +02:00
/* Free vertdup after use*/
MEM_freeN(vertdup);
== Multires == Fixed bug #8215, Crash with shaded view + multires mesh
2008-02-09 21:50:25 +01:00
/* Go to the render level */
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
me->mr->newlvl= me->mr->renderlvl;
== Multires == Fixed bug #6153, Blender Crash during rendering (internal) with object selected in edit mode. * Added a render parameter to several of multires's functions. If render==true, multires won't push data onto the undo stack, and regular Mesh data is always used (as opposed to EditMesh data.)
2007-03-08 06:54:39 +01:00
multires_set_level(ob, me, 1);
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
(*dm)= getMeshDerivedMesh(me, ob, NULL);
/* Some of the data in dm is referenced externally, so make a copy */
old= *dm;
(*dm)= CDDM_copy(old);
old->release(old);
Fixed bug #7981, Crash with multires Caused by incorrect handling of multires with orco mapping
2007-12-23 04:03:54 +01:00
if(dataMask & CD_MASK_ORCO)
add_orco_dm(ob, *dm, NULL);
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
/* Restore the original verts */
me->mr->newlvl= BLI_countlist(&me->mr->levels);
== Multires == Fixed bug #6153, Blender Crash during rendering (internal) with object selected in edit mode. * Added a render parameter to several of multires's functions. If render==true, multires won't push data onto the undo stack, and regular Mesh data is always used (as opposed to EditMesh data.)
2007-03-08 06:54:39 +01:00
multires_set_level(ob, me, 1);
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
for(i=0; i<lvl->totvert; ++i)
VecCopyf(me->mvert[i].co, &vert_copy[i*3]);
Merged Google Summer of Code sculptmode/multires/retopo tools. From the tracker: https://projects.blender.org/tracker/index.php?func=detail&aid=5018&group_id=9&atid=127
2006-11-06 02:08:26 +01:00
}
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
if(vert_copy)
MEM_freeN(vert_copy);
me->mr->newlvl= orig_lvl;
== Multires == Fixed bug #6153, Blender Crash during rendering (internal) with object selected in edit mode. * Added a render parameter to several of multires's functions. If render==true, multires won't push data onto the undo stack, and regular Mesh data is always used (as opposed to EditMesh data.)
2007-03-08 06:54:39 +01:00
multires_set_level(ob, me, 1);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
}
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
}
/* Multires note - if mesh has multires enabled, mesh is first set to the Pin level,
where all modifiers are applied, then if the topology hasn't changed, the changes
from modifiers are propagated up to the Render level. */
DerivedMesh *mesh_create_derived_render(Object *ob, CustomDataMask dataMask)
{
DerivedMesh *final;
Mesh *me= get_mesh(ob);
float *vert_copy= NULL;
int orig_lvl= 0;
vert_copy= multires_render_pin(ob, me, &orig_lvl);
mesh_calc_modifiers(ob, NULL, NULL, &final, 1, 1, 0, dataMask);
Fixed bug #7981, Crash with multires Caused by incorrect handling of multires with orco mapping
2007-12-23 04:03:54 +01:00
multires_render_final(ob, me, &final, vert_copy, orig_lvl, dataMask);
Merged Google Summer of Code sculptmode/multires/retopo tools. From the tracker: https://projects.blender.org/tracker/index.php?func=detail&aid=5018&group_id=9&atid=127
2006-11-06 02:08:26 +01:00
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
return final;
- added dontFreeVerts and dontFreeOther flags to displistmesh for situations where data can be shared easily. - added convertDisplistToMesh function for regular mesh DerivedMesh interface (how many times can *you* use mesh in one sentence?) - do_puno was uninitialized in init_render_mesh - added mesh_get_derived_final (temporary), difference from mesh_get_derived is it always returns a derived mesh, even if no subsurf.
2005-07-16 23:03:28 +02:00
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *mesh_create_derived_view(Object *ob, CustomDataMask dataMask)
added mesh_create_derived_view(ob) to DerivedMesh.c exactly the same as mesh_create_derived_render(ob) except it uses the view modifier settings. Added an optional arg to getFromObject to 'render' so you can choose to get the mesh displayed in the 3d view or generate one with render settings. Solved bug 4612 getFromObject now works with soft body meshes (error was caused by getting the derived mesh from a copy of the object) removed workaround for softbody bug in object_apply_def.py
2006-09-17 07:15:56 +02:00
{
DerivedMesh *final;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mesh_calc_modifiers(ob, NULL, NULL, &final, 0, 1, 0, dataMask);
added mesh_create_derived_view(ob) to DerivedMesh.c exactly the same as mesh_create_derived_render(ob) except it uses the view modifier settings. Added an optional arg to getFromObject to 'render' so you can choose to get the mesh displayed in the 3d view or generate one with render settings. Solved bug 4612 getFromObject now works with soft body meshes (error was caused by getting the derived mesh from a copy of the object) removed workaround for softbody bug in object_apply_def.py
2006-09-17 07:15:56 +02:00
return final;
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *mesh_create_derived_no_deform(Object *ob, float (*vertCos)[3],
CustomDataMask dataMask)
- added DirectMesh.getVert{Co,No} functions - added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 03:18:59 +02:00
{
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
DerivedMesh *final;
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mesh_calc_modifiers(ob, vertCos, NULL, &final, 0, 0, 0, dataMask);
- added DirectMesh.getVert{Co,No} functions - added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 03:18:59 +02:00
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
return final;
- added DirectMesh.getVert{Co,No} functions - added mesh_get_derived_deform function (always returns a DerivedMesh corresponding to deformed (but not subdivided) mesh). used in places where original mesh is to be displayed but with deformed coordinates (vpaint for example). - added DirectMesh.getVert{Co,No} implementations for MeshDerivedMesh - updated vpaint to use mesh_get_derived_deform
2005-07-17 03:18:59 +02:00
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *mesh_create_derived_no_deform_render(Object *ob,
float (*vertCos)[3],
CustomDataMask dataMask)
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
{
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
DerivedMesh *final;
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
Mesh *me= get_mesh(ob);
float *vert_copy= NULL;
int orig_lvl= 0;
- added mesh_get_derived_render - cancelled previous commit to add RE_findTFAce, instead just added a MemArena to render struct... free'd at end of render, can be used to store other data as well - switch rendering to using DerivedMesh API... this is slightly more inefficient now because it is doing some unnecessary copying. Can be fixed by defining a DerivedMesh function to convert the object into a render object (on todo list)
2005-03-28 23:49:49 +02:00
= Multires = Fixed bug #5756, Rendering artifacts when MRM is not set to maximum Several changes were made: * Added function multires_level_n to get the nth level from a multires mesh * Removed the changes I made some time ago to init_render_mesh for multires meshes. Previously it was making a full copy of the mesh object in order to be able to apply deformations to the Pin level and propagate them to the Render level. * Added two functions to DerivedMesh.c, multires_render_pin and multires_render_final. These two functions work together in the mesh_create_derived_*_render functions to apply all modifiers to the Pin level, then create the DerivedMesh from the Render level, and lastly restore the mesh to its original (undeformed) state. * Added a check in multires_del_lower and multires_del_higher to ensure that level indices are properly clipped to the actual range of available levels.
2007-01-22 00:46:00 +01:00
vert_copy= multires_render_pin(ob, me, &orig_lvl);
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
mesh_calc_modifiers(ob, vertCos, NULL, &final, 1, 0, 0, dataMask);
Fixed bug #7981, Crash with multires Caused by incorrect handling of multires with orco mapping
2007-12-23 04:03:54 +01:00
multires_render_final(ob, me, &final, vert_copy, orig_lvl, dataMask);
- change make_orco_displist_mesh to use current editmesh as source if needed. - don't return cached subsurf during editmode, order is messed up (fixes orco rendering).
2005-04-04 14:22:33 +02:00
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
return final;
}
- work-in-progress: subsurf level 0 now just acts like a regular mesh, before it would follow subsurf code path by creating fake displistmesh, etc... kinda fun for testing but just annoying now. - change to creasing behavior, to make sure that with full creasing effect is just simple subdivision.
2005-04-04 05:38:21 +02:00
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
/***/
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *editmesh_get_derived_cage_and_final(DerivedMesh **final_r,
CustomDataMask dataMask)
- change mesh_get_derived_render to mesh_create_derived_render (always builds new DerivedMesh... caching can come later) - split DerivedMesh returning functions into editmesh and mesh groups - got rid of DL_NORS displist type (get built on fly for mesh when needed) - got rid of Mesh.disp (yay!) - started to punch DerivedMesh returning functions into shape to introduce modifier stack
2005-07-19 02:21:01 +02:00
{
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* if there's no derived mesh or the last data mask used doesn't include
* the data we need, rebuild the derived mesh
*/
if(!G.editMesh->derivedCage ||
(G.editMesh->lastDataMask & dataMask) != dataMask)
editmesh_build_data(dataMask);
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
*final_r = G.editMesh->derivedFinal;
return G.editMesh->derivedCage;
NOTE: New file to be added to project files - add new DerivedMesh type, currently just encapsulates drawing
2005-03-27 22:34:18 +02:00
}
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 07:58:43 +02:00
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
DerivedMesh *editmesh_get_derived_cage(CustomDataMask dataMask)
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 07:58:43 +02:00
{
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
/* if there's no derived mesh or the last data mask used doesn't include
* the data we need, rebuild the derived mesh
*/
if(!G.editMesh->derivedCage ||
(G.editMesh->lastDataMask & dataMask) != dataMask)
editmesh_build_data(dataMask);
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 07:58:43 +02:00
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 22:30:33 +02:00
return G.editMesh->derivedCage;
- added mesh_get_cage_derived (returns appropriate DerivedMesh to be used as a cage - depends on ME_OPT_EDGE flag)
2005-03-28 07:58:43 +02:00
}
- added editmhes_get_derived_base, used when a mesh with multiple users is in editmode. current bevahaior is to display the object that is actually in editmode with its modifiers, and all other objects that share the mesh using just the base editmesh data. this is not 100% consistent but no architecture at the moment to display all objects that have mesh in editmode with each individual modifier stack.
2005-08-06 22:44:59 +02:00
DerivedMesh *editmesh_get_derived_base(void)
{
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 03:12:36 +02:00
return getEditMeshDerivedMesh(G.editMesh, G.obedit, NULL);
- added editmhes_get_derived_base, used when a mesh with multiple users is in editmode. current bevahaior is to display the object that is actually in editmode with its modifiers, and all other objects that share the mesh using just the base editmesh data. this is not 100% consistent but no architecture at the moment to display all objects that have mesh in editmode with each individual modifier stack.
2005-08-06 22:44:59 +02:00
}
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
/* ********* For those who don't grasp derived stuff! (ton) :) *************** */
static void make_vertexcosnos__mapFunc(void *userData, int index, float *co, float *no_f, short *no_s)
{
float *vec = userData;
vec+= 6*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 03:12:36 +02:00
/* check if we've been here before (normal should not be 0) */
if(vec[3] || vec[4] || vec[5]) return;
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
VECCOPY(vec, co);
vec+= 3;
if(no_f) {
VECCOPY(vec, no_f);
}
else {
VECCOPY(vec, no_s);
}
}
/* always returns original amount me->totvert of vertices and normals, but fully deformed and subsurfered */
/* this is needed for all code using vertexgroups (no subsurf support) */
/* it stores the normals as floats, but they can still be scaled as shorts (32767 = unit) */
/* in use now by vertex/weight paint and particle generating */
float *mesh_get_mapped_verts_nors(Object *ob)
{
Mesh *me= ob->data;
Removing an extra semi-colon that caused some grief
2005-11-12 15:39:14 +01:00
DerivedMesh *dm;
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
float *vertexcosnos;
/* lets prevent crashing... */
if(ob->type!=OB_MESH || me->totvert==0)
return NULL;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
dm= mesh_get_derived_final(ob, CD_MASK_BAREMESH);
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 03:12:36 +02:00
vertexcosnos= MEM_callocN(6*sizeof(float)*me->totvert, "vertexcosnos map");
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
Bugfix #3437 #3438 - Mirror modifier showed particles on wrong half. Note: particles don't do modifiers yet (apart from using subsurf coords) - Boolean modifier copy didn't copy the 'operation' type.
2005-11-23 20:19:44 +01:00
if(dm->foreachMappedVert) {
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
dm->foreachMappedVert(dm, make_vertexcosnos__mapFunc, vertexcosnos);
Bugfix #3437 #3438 - Mirror modifier showed particles on wrong half. Note: particles don't do modifiers yet (apart from using subsurf coords) - Boolean modifier copy didn't copy the 'operation' type.
2005-11-23 20:19:44 +01:00
}
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
else {
float *fp= vertexcosnos;
int a;
for(a=0; a< me->totvert; a++, fp+=6) {
dm->getVertCo(dm, a, fp);
dm->getVertNo(dm, a, fp+3);
}
}
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
dm->release(dm);
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
return vertexcosnos;
}
Armature CrazySpace Improvement =============================== An improved CrazySpace correction is now used for Armature modifiers that use vertex groups, and that are the first enabled modifiers in the stack. This is a a specific case, but also a common one. http://www.blender.org/development/current-projects/changes-since-244/skinning/ Implementation Notes: - The quaternion crazyspace correction is still used for modifiers other than the armature modifier. - Modifiers can now provide a deform matrix per vertex to be used for crazyspace correction, only the armature modifier implements this now.
2007-07-28 23:04:30 +02:00
/* ********* crazyspace *************** */
int editmesh_get_first_deform_matrices(float (**deformmats)[3][3], float (**deformcos)[3])
{
Object *ob = G.obedit;
EditMesh *em = G.editMesh;
ModifierData *md;
DerivedMesh *dm;
int i, a, numleft = 0, numVerts = 0;
int cageIndex = modifiers_getCageIndex(ob, NULL);
float (*defmats)[3][3] = NULL, (*deformedVerts)[3] = NULL;
modifiers_clearErrors(ob);
dm = NULL;
md = ob->modifiers.first;
/* compute the deformation matrices and coordinates for the first
modifiers with on cage editing that are enabled and support computing
deform matrices */
for(i = 0; md && i <= cageIndex; i++, md = md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if(!editmesh_modifier_is_enabled(md, dm))
continue;
if(mti->type==eModifierTypeType_OnlyDeform && mti->deformMatricesEM) {
if(!defmats) {
dm= getEditMeshDerivedMesh(em, ob, NULL);
deformedVerts= editmesh_getVertexCos(em, &numVerts);
defmats= MEM_callocN(sizeof(*defmats)*numVerts, "defmats");
for(a=0; a<numVerts; a++)
Mat3One(defmats[a]);
}
mti->deformMatricesEM(md, ob, em, dm, deformedVerts, defmats,
numVerts);
}
else
break;
}
for(; md && i <= cageIndex; md = md->next, i++)
if(editmesh_modifier_is_enabled(md, dm) && modifier_isDeformer(md))
numleft++;
if(dm)
dm->release(dm);
*deformmats= defmats;
*deformcos= deformedVerts;
return numleft;
}
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
Game Engine: alpha blending and sorting ======================================= Alpha blending + sorting was revised, to fix bugs and get it to work more predictable. * A new per texture face "Sort" setting defines if the face is alpha sorted or not, instead of abusing the "ZTransp" setting as it did before. * Existing files are converted to hopefully match the old behavior as much as possible with a version patch. * On new meshes the Sort flag is disabled by the default, to avoid unexpected and hard to find slowdowns. * Alpha sorting for faces was incredibly slow. Sorting faces in a mesh with 600 faces lowered the framerate from 200 to 70 fps in my test.. the sorting there case goes about 15x faster now, but it is still advised to use Clip Alpha if possible instead of regular Alpha. * There still various limitations in the alpha sorting code, I've added some comments to the code about this. Some docs at the bottom of the page: http://www.blender.org/development/current-projects/changes-since-246/realtime-glsl-materials/ Merged some fixes from the apricot branch, most important change is that tangents are now exactly the same as the rest of Blender, instead of being computed in the game engine with a different algorithm. Also, the subversion was bumped to 1.
2008-07-29 17:48:31 +02:00
void DM_add_tangent_layer(DerivedMesh *dm)
{
/* mesh vars */
MTFace *mtface, *tf;
MFace *mface, *mf;
MVert *mvert, *v1, *v2, *v3, *v4;
MemArena *arena= NULL;
VertexTangent **vtangents= NULL;
float (*orco)[3]= NULL, (*tangent)[3];
float *uv1, *uv2, *uv3, *uv4, *vtang;
float fno[3], tang[3], uv[4][2];
int i, j, len, mf_vi[4], totvert, totface;
if(CustomData_get_layer_index(&dm->faceData, CD_TANGENT) != -1)
return;
/* check we have all the needed layers */
totvert= dm->getNumVerts(dm);
totface= dm->getNumFaces(dm);
mvert= dm->getVertArray(dm);
mface= dm->getFaceArray(dm);
mtface= dm->getFaceDataArray(dm, CD_MTFACE);
if(!mtface) {
orco= dm->getVertDataArray(dm, CD_ORCO);
if(!orco)
return;
}
/* create tangent layer */
DM_add_face_layer(dm, CD_TANGENT, CD_CALLOC, NULL);
tangent= DM_get_face_data_layer(dm, CD_TANGENT);
/* allocate some space */
arena= BLI_memarena_new(BLI_MEMARENA_STD_BUFSIZE);
BLI_memarena_use_calloc(arena);
vtangents= MEM_callocN(sizeof(VertexTangent*)*totvert, "VertexTangent");
/* sum tangents at connected vertices */
for(i=0, tf=mtface, mf=mface; i < totface; mf++, tf++, i++) {
v1= &mvert[mf->v1];
v2= &mvert[mf->v2];
v3= &mvert[mf->v3];
if (mf->v4) {
v4= &mvert[mf->v4];
CalcNormFloat4(v4->co, v3->co, v2->co, v1->co, fno);
}
else {
v4= NULL;
CalcNormFloat(v3->co, v2->co, v1->co, fno);
}
if(mtface) {
uv1= tf->uv[0];
uv2= tf->uv[1];
uv3= tf->uv[2];
uv4= tf->uv[3];
}
else {
uv1= uv[0]; uv2= uv[1]; uv3= uv[2]; uv4= uv[3];
spheremap(orco[mf->v1][0], orco[mf->v1][1], orco[mf->v1][2], &uv[0][0], &uv[0][1]);
spheremap(orco[mf->v2][0], orco[mf->v2][1], orco[mf->v2][2], &uv[1][0], &uv[1][1]);
spheremap(orco[mf->v3][0], orco[mf->v3][1], orco[mf->v3][2], &uv[2][0], &uv[2][1]);
if(v4)
spheremap(orco[mf->v4][0], orco[mf->v4][1], orco[mf->v4][2], &uv[3][0], &uv[3][1]);
}
tangent_from_uv(uv1, uv2, uv3, v1->co, v2->co, v3->co, fno, tang);
sum_or_add_vertex_tangent(arena, &vtangents[mf->v1], tang, uv1);
sum_or_add_vertex_tangent(arena, &vtangents[mf->v2], tang, uv2);
sum_or_add_vertex_tangent(arena, &vtangents[mf->v3], tang, uv3);
if(mf->v4) {
v4= &mvert[mf->v4];
tangent_from_uv(uv1, uv3, uv4, v1->co, v3->co, v4->co, fno, tang);
sum_or_add_vertex_tangent(arena, &vtangents[mf->v1], tang, uv1);
sum_or_add_vertex_tangent(arena, &vtangents[mf->v3], tang, uv3);
sum_or_add_vertex_tangent(arena, &vtangents[mf->v4], tang, uv4);
}
}
/* write tangent to layer */
for(i=0, tf=mtface, mf=mface; i < totface; mf++, tf++, i++, tangent+=4) {
len= (mf->v4)? 4 : 3;
if(mtface) {
uv1= tf->uv[0];
uv2= tf->uv[1];
uv3= tf->uv[2];
uv4= tf->uv[3];
}
else {
uv1= uv[0]; uv2= uv[1]; uv3= uv[2]; uv4= uv[3];
spheremap(orco[mf->v1][0], orco[mf->v1][1], orco[mf->v1][2], &uv[0][0], &uv[0][1]);
spheremap(orco[mf->v2][0], orco[mf->v2][1], orco[mf->v2][2], &uv[1][0], &uv[1][1]);
spheremap(orco[mf->v3][0], orco[mf->v3][1], orco[mf->v3][2], &uv[2][0], &uv[2][1]);
if(len==4)
spheremap(orco[mf->v4][0], orco[mf->v4][1], orco[mf->v4][2], &uv[3][0], &uv[3][1]);
}
mf_vi[0]= mf->v1;
mf_vi[1]= mf->v2;
mf_vi[2]= mf->v3;
mf_vi[3]= mf->v4;
for(j=0; j<len; j++) {
vtang= find_vertex_tangent(vtangents[mf_vi[j]], mtface ? tf->uv[j] : uv[j]);
VECCOPY(tangent[j], vtang);
Normalize(tangent[j]);
}
}
BLI_memarena_free(arena);
MEM_freeN(vtangents);
}
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
/* ************************* fluidsim bobj file handling **************************** */
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- modified patch #4681, for scons compiling of the fluidsim can now be disabled with the flag: BF_NO_ELBEEM='true', e.g. for irix systems. (The number of ifdefs from the original patch was reduced, and the defines are now only necessary when elbeem is switched off.) - particle generation option is available again
2006-08-22 13:18:00 +02:00
#ifndef DISABLE_ELBEEM
- minor fix of snprintf defines for MSVC - fix for 2d domains was part of the previous checking as well, btw. :)
2005-11-09 12:10:15 +01:00
#ifdef WIN32
#ifndef snprintf
#define snprintf _snprintf
#endif
#endif
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- minor fix of snprintf defines for MSVC - fix for 2d domains was part of the previous checking as well, btw. :)
2005-11-09 12:10:15 +01:00
/* write .bobj.gz file for a mesh object */
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
void writeBobjgz(char *filename, struct Object *ob, int useGlobalCoords, int append, float time)
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
{
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
char debugStrBuffer[256];
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
int wri,i,j,totvert,totface;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
float wrf;
gzFile gzf;
DerivedMesh *dm;
float vec[3];
float rotmat[3][3];
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MVert *mvert;
MFace *mface;
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
//if(append)return; // DEBUG
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
if(!ob->data || (ob->type!=OB_MESH)) {
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256,"Writing GZ_BOBJ Invalid object %s ...\n", ob->id.name);
elbeemDebugOut(debugStrBuffer);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
return;
}
if((ob->size[0]<0.0) || (ob->size[0]<0.0) || (ob->size[0]<0.0) ) {
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256,"\nfluidSim::writeBobjgz:: Warning object %s has negative scaling - check triangle ordering...?\n\n", ob->id.name);
elbeemDebugOut(debugStrBuffer);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256,"Writing GZ_BOBJ '%s' ... ",filename); elbeemDebugOut(debugStrBuffer);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
if(append) gzf = gzopen(filename, "a+b9");
else gzf = gzopen(filename, "wb9");
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
if (!gzf) {
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256,"writeBobjgz::error - Unable to open file for writing '%s'\n", filename);
elbeemDebugOut(debugStrBuffer);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
return;
}
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
dm = mesh_create_derived_render(ob, CD_MASK_BAREMESH);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
//dm = mesh_create_derived_no_deform(ob,NULL);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
mvert = dm->getVertArray(dm);
mface = dm->getFaceArray(dm);
totvert = dm->getNumVerts(dm);
totface = dm->getNumFaces(dm);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
// write time value for appended anim mesh
if(append) {
gzwrite(gzf, &time, sizeof(time));
}
// continue with verts/norms
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
if(sizeof(wri)!=4) { snprintf(debugStrBuffer,256,"Writing GZ_BOBJ, Invalid int size %d...\n", wri); elbeemDebugOut(debugStrBuffer); return; } // paranoia check
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
wri = dm->getNumVerts(dm);
mvert = dm->getVertArray(dm);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzwrite(gzf, &wri, sizeof(wri));
for(i=0; i<wri;i++) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
VECCOPY(vec, mvert[i].co);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
if(useGlobalCoords) { Mat4MulVecfl(ob->obmat, vec); }
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
for(j=0; j<3; j++) {
wrf = vec[j];
gzwrite(gzf, &wrf, sizeof( wrf ));
}
}
// should be the same as Vertices.size
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
wri = totvert;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzwrite(gzf, &wri, sizeof(wri));
EulToMat3(ob->rot, rotmat);
for(i=0; i<wri;i++) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
VECCOPY(vec, mvert[i].no);
moved source and text to american spelling * colour -> color * centre -> center * normalise -> normalize * modelling -> modeling
2007-04-04 15:18:41 +02:00
Normalize(vec);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
if(useGlobalCoords) { Mat3MulVecfl(rotmat, vec); }
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
for(j=0; j<3; j++) {
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
wrf = vec[j];
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzwrite(gzf, &wrf, sizeof( wrf ));
}
}
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
// append only writes verts&norms
if(!append) {
//float side1[3],side2[3],norm1[3],norm2[3];
//float inpf;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
// compute no. of triangles
wri = 0;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i=0; i<totface; i++) {
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
wri++;
if(mface[i].v4) { wri++; }
}
gzwrite(gzf, &wri, sizeof(wri));
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i=0; i<totface; i++) {
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
int face[4];
face[0] = mface[i].v1;
face[1] = mface[i].v2;
face[2] = mface[i].v3;
face[3] = mface[i].v4;
//snprintf(debugStrBuffer,256,"F %s %d = %d,%d,%d,%d \n",ob->id.name, i, face[0],face[1],face[2],face[3] ); elbeemDebugOut(debugStrBuffer);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
//VecSubf(side1, mvert[face[1]].co,mvert[face[0]].co);
//VecSubf(side2, mvert[face[2]].co,mvert[face[0]].co);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
//Crossf(norm1,side1,side2);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzwrite(gzf, &(face[0]), sizeof( face[0] ));
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
gzwrite(gzf, &(face[1]), sizeof( face[1] ));
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzwrite(gzf, &(face[2]), sizeof( face[2] ));
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
if(face[3]) {
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
//VecSubf(side1, mvert[face[2]].co,mvert[face[0]].co);
//VecSubf(side2, mvert[face[3]].co,mvert[face[0]].co);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
//Crossf(norm2,side1,side2);
//inpf = Inpf(norm1,norm2);
//if(inpf>0.) {
gzwrite(gzf, &(face[0]), sizeof( face[0] ));
gzwrite(gzf, &(face[2]), sizeof( face[2] ));
gzwrite(gzf, &(face[3]), sizeof( face[3] ));
//} else {
//gzwrite(gzf, &(face[0]), sizeof( face[0] ));
//gzwrite(gzf, &(face[3]), sizeof( face[3] ));
//gzwrite(gzf, &(face[2]), sizeof( face[2] ));
//}
} // quad
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
}
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
snprintf(debugStrBuffer,256,"Done. #Vertices: %d, #Triangles: %d\n", totvert, totface );
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
elbeemDebugOut(debugStrBuffer);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzclose( gzf );
dm->release(dm);
}
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
void initElbeemMesh(struct Object *ob,
int *numVertices, float **vertices,
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
int *numTriangles, int **triangles,
int useGlobalCoords)
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
{
DerivedMesh *dm = NULL;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
MVert *mvert;
MFace *mface;
int countTris=0, i, totvert, totface;
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
float *verts;
int *tris;
Modifier Stack: Limit calculation to required data. This commit upgrades the modifier stack to only calculate the data which is needed, either by modifiers further down the stack or by other functions at the end of the stack (e.g. drawing functions). This speeds up modifier stack recalculation, especially where vertex groups and UV coordinates are concerned. For example, a mesh with an Armature modifier followed by a Subsurf modifier would previously have required the Subsurf modifier to interpolate all the vertex groups in the mesh, slowing down modifier calculations considerably. With this update, vertex group data is not propagated beyond the Armature modifier, so calculations are faster. Note that this depends on the order of modifiers in the stack. If the Armature and Subsurf modifiers were swapped in the above example, the Subsurf modifier would have to interpolate vertex groups, as they are needed by the Armature modifier.
2006-12-05 18:42:03 +01:00
dm = mesh_create_derived_render(ob, CD_MASK_BAREMESH);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
//dm = mesh_create_derived_no_deform(ob,NULL);
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
mvert = dm->getVertArray(dm);
mface = dm->getFaceArray(dm);
totvert = dm->getNumVerts(dm);
totface = dm->getNumFaces(dm);
*numVertices = totvert;
verts = MEM_callocN( totvert*3*sizeof(float), "elbeemmesh_vertices");
for(i=0; i<totvert; i++) {
VECCOPY( &verts[i*3], mvert[i].co);
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
if(useGlobalCoords) { Mat4MulVecfl(ob->obmat, &verts[i*3]); }
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
}
*vertices = verts;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i=0; i<totface; i++) {
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
countTris++;
if(mface[i].v4) { countTris++; }
}
*numTriangles = countTris;
tris = MEM_callocN( countTris*3*sizeof(int), "elbeemmesh_triangles");
countTris = 0;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
for(i=0; i<totface; i++) {
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
int face[4];
face[0] = mface[i].v1;
face[1] = mface[i].v2;
face[2] = mface[i].v3;
face[3] = mface[i].v4;
tris[countTris*3+0] = face[0];
tris[countTris*3+1] = face[1];
tris[countTris*3+2] = face[2];
countTris++;
if(face[3]) {
tris[countTris*3+0] = face[0];
tris[countTris*3+1] = face[2];
tris[countTris*3+2] = face[3];
countTris++;
}
}
*triangles = tris;
dm->release(dm);
}
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
/* read .bobj.gz file into a fluidsimDerivedMesh struct */
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
Mesh* readBobjgz(char *filename, Mesh *orgmesh, float* bbstart, float *bbsize) //, fluidsimDerivedMesh *fsdm)
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
{
int wri,i,j;
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
char debugStrBuffer[256];
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
float wrf;
Mesh *newmesh;
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
const int debugBobjRead = 1;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
// init data from old mesh (materials,flags)
MFace *origMFace = &((MFace*) orgmesh->mface)[0];
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
int mat_nr = -1;
int flag = -1;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
MFace *fsface = NULL;
int gotBytes;
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
gzFile gzf;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
if(!orgmesh) return NULL;
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
if(!origMFace) return NULL;
mat_nr = origMFace->mat_nr;
flag = origMFace->flag;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
// similar to copy_mesh
newmesh = MEM_dupallocN(orgmesh);
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
newmesh->mat= orgmesh->mat;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
newmesh->mvert= NULL;
newmesh->medge= NULL;
newmesh->mface= NULL;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
newmesh->mtface= NULL;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
newmesh->dvert = NULL;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
newmesh->mcol= NULL;
newmesh->msticky= NULL;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
newmesh->texcomesh= NULL;
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
memset(&newmesh->vdata, 0, sizeof(newmesh->vdata));
memset(&newmesh->edata, 0, sizeof(newmesh->edata));
memset(&newmesh->fdata, 0, sizeof(newmesh->fdata));
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
newmesh->key= NULL;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
newmesh->totface = 0;
newmesh->totvert = 0;
newmesh->totedge = 0;
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
newmesh->medge = NULL;
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256,"Reading '%s' GZ_BOBJ... ",filename); elbeemDebugOut(debugStrBuffer);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gzf = gzopen(filename, "rb");
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
// gzf = fopen(filename, "rb");
// debug: fread(b,c,1,a) = gzread(a,b,c)
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
if (!gzf) {
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
//snprintf(debugStrBuffer,256,"readBobjgz::error - Unable to open file for reading '%s'\n", filename); // DEBUG
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
MEM_freeN(newmesh);
return NULL;
}
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
//if(sizeof(wri)!=4) { snprintf(debugStrBuffer,256,"Reading GZ_BOBJ, Invalid int size %d...\n", wri); return NULL; } // paranoia check
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
gotBytes = gzread(gzf, &wri, sizeof(wri));
newmesh->totvert = wri;
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 22:29:09 +01:00
newmesh->mvert = CustomData_add_layer(&newmesh->vdata, CD_MVERT, CD_CALLOC, NULL, newmesh->totvert);
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
if(debugBobjRead){ snprintf(debugStrBuffer,256,"#vertices %d ", newmesh->totvert); elbeemDebugOut(debugStrBuffer); } //DEBUG
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
for(i=0; i<newmesh->totvert;i++) {
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
//if(debugBobjRead) snprintf(debugStrBuffer,256,"V %d = ",i);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
for(j=0; j<3; j++) {
gotBytes = gzread(gzf, &wrf, sizeof( wrf ));
newmesh->mvert[i].co[j] = wrf;
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
//if(debugBobjRead) snprintf(debugStrBuffer,256,"%25.20f ", wrf);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
//if(debugBobjRead) snprintf(debugStrBuffer,256,"\n");
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
// should be the same as Vertices.size
gotBytes = gzread(gzf, &wri, sizeof(wri));
if(wri != newmesh->totvert) {
// complain #vertices has to be equal to #normals, reset&abort
Select Grouped editdata- minor fix in the menu. Updated Python Mesh API to support UV and Color layers with names. Similar to vertex group's renamed a function in customdata.c CustomData_free_layers -> CustomData_free_layers_active and made CustomData_free_layers accept an index, this is needed so python could free layers that arnt active.
2006-12-23 18:07:02 +01:00
CustomData_free_layer_active(&newmesh->vdata, CD_MVERT, newmesh->totvert);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
MEM_freeN(newmesh);
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256,"Reading GZ_BOBJ, #normals=%d, #vertices=%d, aborting...\n", wri,newmesh->totvert );
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
return NULL;
}
for(i=0; i<newmesh->totvert;i++) {
for(j=0; j<3; j++) {
gotBytes = gzread(gzf, &wrf, sizeof( wrf ));
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
newmesh->mvert[i].no[j] = (short)(wrf*32767.0f);
//newmesh->mvert[i].no[j] = 0.5; // DEBUG tst
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
//fprintf(stderr," DEBDPCN nm%d, %d = %d,%d,%d \n",
//(int)(newmesh->mvert), i, newmesh->mvert[i].no[0], newmesh->mvert[i].no[1], newmesh->mvert[i].no[2]);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
//fprintf(stderr," DPCN 0 = %d,%d,%d \n", newmesh->mvert[0].no[0], newmesh->mvert[0].no[1], newmesh->mvert[0].no[2]);
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
/* compute no. of triangles */
gotBytes = gzread(gzf, &wri, sizeof(wri));
newmesh->totface = wri;
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 22:29:09 +01:00
newmesh->mface = CustomData_add_layer(&newmesh->fdata, CD_MFACE, CD_CALLOC, NULL, newmesh->totface);
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
if(debugBobjRead){ snprintf(debugStrBuffer,256,"#faces %d ", newmesh->totface); elbeemDebugOut(debugStrBuffer); } //DEBUG
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
fsface = newmesh->mface;
for(i=0; i<newmesh->totface; i++) {
int face[4];
gotBytes = gzread(gzf, &(face[0]), sizeof( face[0] ));
gotBytes = gzread(gzf, &(face[1]), sizeof( face[1] ));
gotBytes = gzread(gzf, &(face[2]), sizeof( face[2] ));
face[3] = 0;
fsface[i].v1 = face[0];
fsface[i].v2 = face[1];
fsface[i].v3 = face[2];
fsface[i].v4 = face[3];
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
}
// correct triangles with v3==0 for blender, cycle verts
for(i=0; i<newmesh->totface; i++) {
if(!fsface[i].v3) {
int temp = fsface[i].v1;
fsface[i].v1 = fsface[i].v2;
fsface[i].v2 = fsface[i].v3;
fsface[i].v3 = temp;
}
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
gzclose( gzf );
for(i=0;i<newmesh->totface;i++) {
fsface[i].mat_nr = mat_nr;
fsface[i].flag = flag;
- merged latest version of fluid solver (fixed shadowed variables warnings, removed cfgparser.hpp, added cfgparser.h, removed debugging output) - added support for env. var BLENDER_ELBEEMDEBUG to enable debugging output again - fixed missing triangle display (marching cubes produced v3=0 triangles) - fixed geometry init bug (nearest intersection check for intersecting objects was messed up) - changed position of derived mesh creation in DerivedMesh.c (for some reason the useDeform code is necessary, without it or with useDeform=0 nothing is displayed) - 3dviews now update every 2 seconds to show simulation progress - note: mesh_strip_loose_faces(me); in ./source/blender/blenkernel/intern/mesh.c:937 not necessary anymore?
2005-09-23 16:42:14 +02:00
fsface[i].edcode = ME_V1V2 | ME_V2V3 | ME_V3V1;
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
//snprintf(debugStrBuffer,256,"%d : %d,%d,%d\n", i,fsface[i].mat_nr, fsface[i].flag, fsface[i].edcode );
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
}
- removed some unecessary files & code - debug output now controlled globally by elbeem debug level (BLENDER_ELBEEMDEBUG environment var), also for fluidsimBake and read/writeBobj - debug output is written to file for WIN32 - added "for" and "vector" etc. defines for MSVC6 (I couldnt get hold of the compiler itself, so not tested yet)
2005-09-28 18:20:57 +02:00
snprintf(debugStrBuffer,256," (%d,%d) done\n", newmesh->totvert,newmesh->totface); elbeemDebugOut(debugStrBuffer); //DEBUG
initial commit of the fluid simulator. Ton reviewed and gave his blessing. Zr, can you have a look ? see : http://projects.blender.org/tracker/?func=detail&atid=127&aid=3039&group_id=9 for initial comments. N_T : the solver itself (elbeem) needs some works to get rid of warnings
2005-09-18 15:27:12 +02:00
return newmesh;
}
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
/* read zipped fluidsim velocities into the co's of the fluidsimsettings normals struct */
void readVelgz(char *filename, Object *srcob)
{
char debugStrBuffer[256];
int wri, i, j;
float wrf;
gzFile gzf;
MVert *vverts = srcob->fluidsimSettings->meshSurfNormals;
int len = strlen(filename);
Mesh *mesh = srcob->data;
// mesh and vverts have to be valid from loading...
// clean up in any case
for(i=0; i<mesh->totvert;i++) {
for(j=0; j<3; j++) {
vverts[i].co[j] = 0.;
}
}
Several minor fixes: - Added part of Austin's msvc8 fixes (vector::erase function was "misused"), hopefully compiles better now. - Ctrl-b now also bakes a selected fluidsim domain similar to the softbodies. - Added surface smoothing option for domains: default is 1, higher values result in a smoother surface (and probably slightly higher comupation times), while 0 means the surface is not modified at all. - Added BLENDER_ELBEEMBOBJABORT environment variable in readBobj, if >0 quits blender when a not yet existing fluidsim frame should be loaded. Useful for rendering simulations as far as possible from the command line. - Surface normals pointer is now set to NULL in readfile.c - Fixed win32 error string handling, now uses a function to return the string from the solver. - Fixed fluidsim particle halo scaling problem. - Solver update
2006-03-29 09:35:54 +02:00
if(srcob->fluidsimSettings->domainNovecgen>0) return;
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
if(len<7) {
//printf("readVelgz Eror: invalid filename '%s'\n",filename); // DEBUG
return;
}
// .bobj.gz , correct filename
// 87654321
filename[len-6] = 'v';
filename[len-5] = 'e';
filename[len-4] = 'l';
snprintf(debugStrBuffer,256,"Reading '%s' GZ_VEL... ",filename); elbeemDebugOut(debugStrBuffer);
gzf = gzopen(filename, "rb");
if (!gzf) {
//printf("readVelgz Eror: unable to open file '%s'\n",filename); // DEBUG
return;
}
gzread(gzf, &wri, sizeof( wri ));
if(wri != mesh->totvert) {
//printf("readVelgz Eror: invalid no. of velocities %d vs. %d aborting.\n" ,wri ,mesh->totvert ); // DEBUG
return;
}
for(i=0; i<mesh->totvert;i++) {
for(j=0; j<3; j++) {
gzread(gzf, &wrf, sizeof( wrf ));
vverts[i].co[j] = wrf;
}
//if(i<20) fprintf(stderr, "GZ_VELload %d = %f,%f,%f \n",i,vverts[i].co[0],vverts[i].co[1],vverts[i].co[2]); // DEBUG
}
gzclose(gzf);
}
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
/* ***************************** fluidsim derived mesh ***************************** */
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
/* check which file to load, and replace old mesh of the object with it */
/* this replacement is undone at the end of mesh_calc_modifiers */
void loadFluidsimMesh(Object *srcob, int useRenderParams)
Particles now are generated from subsurfed coordinates. Note that the current default generates particles based on the original amount of vertices and faces, this for vertex group support (which is not subdivided with modifiers). That means that particles generated on subsurfed faces still have minor approximation errors. Note for DerivedMesh users; I've added a new API call: float *mesh_get_mapped_verts_nors(Object *ob); Which returns an array of 2 * 3 * float size, containing the vertices and normals, deformed and subsurfered, but only the original me->mvert amount. Works in all non-editmode cases. Is in use now for vertex/weight paint and particles.
2005-11-12 11:35:14 +01:00
{
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
Mesh *mesh = NULL;
Bugfix #3437 #3438 - Mirror modifier showed particles on wrong half. Note: particles don't do modifiers yet (apart from using subsurf coords) - Boolean modifier copy didn't copy the 'operation' type.
2005-11-23 20:19:44 +01:00
float *bbStart = NULL, *bbSize = NULL;
float lastBB[3];
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
int displaymode = 0;
Three minor fixes: - removed debugging output from fluidsim export - directores with "+" are now valid for fluidsim data - simulation now always uses frame 1 to endframe, so changing start frame settings should work again
2006-01-05 16:49:27 +01:00
int curFrame = G.scene->r.cfra - 1 /*G.scene->r.sfra*/; /* start with 0 at start frame */
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
char targetDir[FILE_MAXFILE+FILE_MAXDIR], targetFile[FILE_MAXFILE+FILE_MAXDIR];
char debugStrBuffer[256];
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
//snprintf(debugStrBuffer,256,"loadFluidsimMesh call (obid '%s', rp %d)\n", srcob->id.name, useRenderParams); // debug
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
if((!srcob)||(!srcob->fluidsimSettings)) {
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
snprintf(debugStrBuffer,256,"DEBUG - Invalid loadFluidsimMesh call, rp %d, dm %d)\n", useRenderParams, displaymode); // debug
elbeemDebugOut(debugStrBuffer); // debug
return;
}
// make sure the original mesh data pointer is stored
if(!srcob->fluidsimSettings->orgMesh) {
srcob->fluidsimSettings->orgMesh = srcob->data;
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
}
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
// free old mesh, if there is one (todo, check if it's still valid?)
if(srcob->fluidsimSettings->meshSurface) {
Mesh *freeFsMesh = srcob->fluidsimSettings->meshSurface;
// similar to free_mesh(...) , but no things like unlink...
Added custom vertex/edge/face data for meshes: All data layers, including MVert/MEdge/MFace, are now managed as custom data layers. The pointers like Mesh.mvert, Mesh.dvert or Mesh.mcol are still used of course, but allocating, copying or freeing these arrays should be done through the CustomData API. Work in progress documentation on this is here: http://mediawiki.blender.org/index.php/BlenderDev/BlenderArchitecture/CustomData Replaced TFace by MTFace: This is the same struct, except that it does not contain color, that now always stays separated in MCol. This was not a good design decision to begin with, and it is needed for adding multiple color layers later. Note that this does mean older Blender versions will not be able to read UV coordinates from the next release, due to an SDNA limitation. Removed DispListMesh: This now fully replaced by DerivedMesh. To provide access to arrays of vertices, edges and faces, like DispListMesh does. The semantics of the DerivedMesh.getVertArray() and similar functions were changed to return a pointer to an array if one exists, or otherwise allocate a temporary one. On releasing the DerivedMesh, this temporary array will be removed automatically. Removed ssDM and meshDM DerivedMesh backends: The ssDM backend was for DispListMesh, so that became obsolete automatically. The meshDM backend was replaced by the custom data backend, that now figures out which layers need to be modified, and only duplicates those. This changes code in many places, and overall removes 2514 lines of code. So, there's a good chance this might break some stuff, although I've been testing it for a few days now. The good news is, adding multiple color and uv layers should now become easy.
2006-11-20 05:28:02 +01:00
CustomData_free(&freeFsMesh->vdata, freeFsMesh->totvert);
CustomData_free(&freeFsMesh->edata, freeFsMesh->totedge);
CustomData_free(&freeFsMesh->fdata, freeFsMesh->totface);
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
MEM_freeN(freeFsMesh);
if(srcob->data == srcob->fluidsimSettings->meshSurface)
srcob->data = srcob->fluidsimSettings->orgMesh;
srcob->fluidsimSettings->meshSurface = NULL;
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
if(srcob->fluidsimSettings->meshSurfNormals) MEM_freeN(srcob->fluidsimSettings->meshSurfNormals);
srcob->fluidsimSettings->meshSurfNormals = NULL;
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
}
// init bounding box
bbStart = srcob->fluidsimSettings->bbStart;
bbSize = srcob->fluidsimSettings->bbSize;
lastBB[0] = bbSize[0]; // TEST
lastBB[1] = bbSize[1];
lastBB[2] = bbSize[2];
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
fluidsimGetAxisAlignedBB(srcob->fluidsimSettings->orgMesh, srcob->obmat, bbStart, bbSize, &srcob->fluidsimSettings->meshBB);
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
// check free fsmesh... TODO
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
if(!useRenderParams) {
displaymode = srcob->fluidsimSettings->guiDisplayMode;
} else {
displaymode = srcob->fluidsimSettings->renderDisplayMode;
}
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
snprintf(debugStrBuffer,256,"loadFluidsimMesh call (obid '%s', rp %d, dm %d), curFra=%d, sFra=%d #=%d \n",
srcob->id.name, useRenderParams, displaymode, G.scene->r.cfra, G.scene->r.sfra, curFrame ); // debug
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
elbeemDebugOut(debugStrBuffer); // debug
strncpy(targetDir, srcob->fluidsimSettings->surfdataPath, FILE_MAXDIR);
// use preview or final mesh?
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
if(displaymode==1) {
// just display original object
srcob->data = srcob->fluidsimSettings->orgMesh;
return;
} else if(displaymode==2) {
Changed BLI_convertstringcode to replace any number of hashes with the frame number. somefile_##.png -> somefile_01.png somefile_########-image.png -> somefile_00000001-image.png Before, A hash at the end of the string would be replaced by a number with 4 characters. This is still default if no #'s are in the string, so nothing has changed. To use this function from the python api use scene.render.getFrameFilename()
2008-04-11 17:47:21 +02:00
strcat(targetDir,"fluidsurface_preview_####");
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
} else { // 3
Changed BLI_convertstringcode to replace any number of hashes with the frame number. somefile_##.png -> somefile_01.png somefile_########-image.png -> somefile_00000001-image.png Before, A hash at the end of the string would be replaced by a number with 4 characters. This is still default if no #'s are in the string, so nothing has changed. To use this function from the python api use scene.render.getFrameFilename()
2008-04-11 17:47:21 +02:00
strcat(targetDir,"fluidsurface_final_####");
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
}
Changed frame numbering to only alter hashes if they are in the filename (not the directory name) to fix bug [#10566] File Open Dialog replaces '#' with '0' in directory names. removed frame numbering from BLI_convertstringcode into its own function (BLI_convertstringframe), many uses of BLI_convertstringcode were passing dummy frames values anyway. in cases where adding the current frame number to a filename is needed run BLI_convertstringframe(...) after BLI_convertstringcode(...) There are some cases Im not sure BLI_convertstringframe is needed, these have been commented as todo, but at least have the same functionality they used to.
2008-05-04 11:41:15 +02:00
BLI_convertstringcode(targetDir, G.sce);
BLI_convertstringframe(targetDir, curFrame); // fixed #frame-no
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
strcpy(targetFile,targetDir);
strcat(targetFile, ".bobj.gz");
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
snprintf(debugStrBuffer,256,"loadFluidsimMesh call (obid '%s', rp %d, dm %d) '%s' \n", srcob->id.name, useRenderParams, displaymode, targetFile); // debug
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
elbeemDebugOut(debugStrBuffer); // debug
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
if(displaymode!=2) { // dont add bounding box for final
mesh = readBobjgz(targetFile, srcob->fluidsimSettings->orgMesh ,NULL,NULL);
} else {
mesh = readBobjgz(targetFile, srcob->fluidsimSettings->orgMesh, bbSize,bbSize );
}
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
if(!mesh) {
Several minor fixes: - Added part of Austin's msvc8 fixes (vector::erase function was "misused"), hopefully compiles better now. - Ctrl-b now also bakes a selected fluidsim domain similar to the softbodies. - Added surface smoothing option for domains: default is 1, higher values result in a smoother surface (and probably slightly higher comupation times), while 0 means the surface is not modified at all. - Added BLENDER_ELBEEMBOBJABORT environment variable in readBobj, if >0 quits blender when a not yet existing fluidsim frame should be loaded. Useful for rendering simulations as far as possible from the command line. - Surface normals pointer is now set to NULL in readfile.c - Fixed win32 error string handling, now uses a function to return the string from the solver. - Fixed fluidsim particle halo scaling problem. - Solver update
2006-03-29 09:35:54 +02:00
// switch, abort background rendering when fluidsim mesh is missing
const char *strEnvName2 = "BLENDER_ELBEEMBOBJABORT"; // from blendercall.cpp
if(G.background==1) {
if(getenv(strEnvName2)) {
int elevel = atoi(getenv(strEnvName2));
if(elevel>0) {
- New options for mesh voxelization: shell only (also works for non closed objects), volume ("normal"/old way of doing it), and a combination of both: http://www10.informatik.uni-erlangen.de/~sinithue/blender/voltcomp_sm.jpg - Finally included bjornmose MSVC6 fixes - Added support for animated meshes, e.g. meshes with parented skeletons. Is enabled for obstacles with a new button. A simple example with Bassam's mancandy can be found here: http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.mpg http://www10.informatik.uni-erlangen.de/~sinithue/blender/fluid2_mancandy.blend (Warning - keep meshes as simple as possible, e.g. turn off subsurf for baking. Export probably shoulb be further optimized.) - Changed handling of no/free/part slip obstacles, see: http://www10.informatik.uni-erlangen.de/~sinithue/blender/bndtcomp_sm.jpg - Removed surface particle option for upcoming release, needs more testing & tweaking - Added tracer particles instead (swimming along in the fluid) - Updated wiki (description of IPOs still missing).
2006-05-11 10:09:02 +02:00
printf("Env. var %s set, fluid sim mesh '%s' not found, aborting render...\n",strEnvName2, targetFile);
Several minor fixes: - Added part of Austin's msvc8 fixes (vector::erase function was "misused"), hopefully compiles better now. - Ctrl-b now also bakes a selected fluidsim domain similar to the softbodies. - Added surface smoothing option for domains: default is 1, higher values result in a smoother surface (and probably slightly higher comupation times), while 0 means the surface is not modified at all. - Added BLENDER_ELBEEMBOBJABORT environment variable in readBobj, if >0 quits blender when a not yet existing fluidsim frame should be loaded. Useful for rendering simulations as far as possible from the command line. - Surface normals pointer is now set to NULL in readfile.c - Fixed win32 error string handling, now uses a function to return the string from the solver. - Fixed fluidsim particle halo scaling problem. - Solver update
2006-03-29 09:35:54 +02:00
exit(1);
}
}
}
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
// display org. object upon failure
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
srcob->data = srcob->fluidsimSettings->orgMesh;
return;
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
}
if((mesh)&&(mesh->totvert>0)) {
make_edges(mesh, 0); // 0 = make all edges draw
}
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
srcob->fluidsimSettings->meshSurface = mesh;
srcob->data = mesh;
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
srcob->fluidsimSettings->meshSurfNormals = MEM_dupallocN(mesh->mvert);
// load vertex velocities, if they exist...
// TODO? use generate flag as loading flag as well?
// warning, needs original .bobj.gz mesh loading filename
if(displaymode==3) {
readVelgz(targetFile, srcob);
} else {
// no data for preview, only clear...
int i,j;
for(i=0; i<mesh->totvert;i++) { for(j=0; j<3; j++) { srcob->fluidsimSettings->meshSurfNormals[i].co[j] = 0.; }}
}
//fprintf(stderr,"LOADFLM DEBXHCH fs=%d 3:%d,%d,%d \n", (int)mesh, ((Mesh *)(srcob->fluidsimSettings->meshSurface))->mvert[3].no[0], ((Mesh *)(srcob->fluidsimSettings->meshSurface))->mvert[3].no[1], ((Mesh *)(srcob->fluidsimSettings->meshSurface))->mvert[3].no[2]);
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
return;
}
/* helper function */
/* init axis aligned BB for mesh object */
void fluidsimGetAxisAlignedBB(struct Mesh *mesh, float obmat[][4],
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
/*RET*/ float start[3], /*RET*/ float size[3], /*RET*/ struct Mesh **bbmesh )
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
{
float bbsx=0.0, bbsy=0.0, bbsz=0.0;
float bbex=1.0, bbey=1.0, bbez=1.0;
int i;
float vec[3];
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
VECCOPY(vec, mesh->mvert[0].co);
Mat4MulVecfl(obmat, vec);
bbsx = vec[0]; bbsy = vec[1]; bbsz = vec[2];
bbex = vec[0]; bbey = vec[1]; bbez = vec[2];
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
for(i=1; i<mesh->totvert;i++) {
VECCOPY(vec, mesh->mvert[i].co);
Mat4MulVecfl(obmat, vec);
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
- changed DerivedMesh integration, the fluidsim meshes now replace the original one. so modifiers now work with them (apply modifier, or edit mode still work on original mesh). this should fix the three fluidsim bugs in the tracker. - fixed stupid makesdna problem (writing "char string[160+80]" isnt a good idea :) - changed GUI a bit, now displays an estimate of the required memory, there's still a problem with redrawing (currently relies on a call to the derived mesh generation) - the fluidsim struct changed to store the bounding box, and the current loaded surface mesh - temporary simulation files are now removed if env. var. BLENDER_DELETEELBEEMFILES is not set or zero - fluidsimSettingsFree now gets properly called when freeing an object
2005-11-23 13:49:22 +01:00
if(vec[0] < bbsx){ bbsx= vec[0]; }
if(vec[1] < bbsy){ bbsy= vec[1]; }
if(vec[2] < bbsz){ bbsz= vec[2]; }
if(vec[0] > bbex){ bbex= vec[0]; }
if(vec[1] > bbey){ bbey= vec[1]; }
if(vec[2] > bbez){ bbez= vec[2]; }
}
// return values...
if(start) {
start[0] = bbsx;
start[1] = bbsy;
start[2] = bbsz;
}
if(size) {
size[0] = bbex-bbsx;
size[1] = bbey-bbsy;
size[2] = bbez-bbsz;
}
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
// init bounding box mesh?
if(bbmesh) {
int i,j;
Mesh *newmesh = NULL;
if(!(*bbmesh)) { newmesh = MEM_callocN(sizeof(Mesh), "fluidsimGetAxisAlignedBB_meshbb"); }
else { newmesh = *bbmesh; }
newmesh->totvert = 8;
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 22:29:09 +01:00
if(!newmesh->mvert)
newmesh->mvert = CustomData_add_layer(&newmesh->vdata, CD_MVERT, CD_CALLOC, NULL, newmesh->totvert);
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
for(i=0; i<8; i++) {
for(j=0; j<3; j++) newmesh->mvert[i].co[j] = start[j];
}
newmesh->totface = 6;
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 22:29:09 +01:00
if(!newmesh->mface)
newmesh->mface = CustomData_add_layer(&newmesh->fdata, CD_MFACE, CD_CALLOC, NULL, newmesh->totface);
Sorry for the big commit, but I've been fixing many of these issues in parallel... So this commit contains: an update of the solver (e.g. moving objects), integration of blender IPOs, improved rendering (motion blur, smoothed normals) and a first particle test. In more detail: Solver update: - Moving objects using a relatively simple model, and not yet fully optimized - ok for box falling into water, water in a moving glass might cause trouble. Simulation times are influenced by overall no. of triangles of the mesh, scaling meshes up a lot might also cause slowdowns. - Additional obstacle settings: noslip (as before), free slip (move along wall freely) and part slip (mix of both). - Obstacle settings also added for domain boundaries now, the six walls of the domain are obstacles after all as well - Got rid of templates, should make compiling for e.g. macs more convenient, for linux there's not much difference. Finally got rid of parser (and some other code parts), the simulation now uses the internal API to transfer data. - Some unnecessary file were removed, the GUI now needs 3 settings buttons... This should still be changed (maybe by adding a new panel for domain objects). IPOs: - Animated params: viscosity, time and gravity for domains. In contrast to normal time IPO for Blender objects, the fluidsim one scales the time step size - so a constant 1 has no effect, values towards 0 slow it down, larger ones speed the simulation up (-> longer time steps, more compuations). The viscosity IPO is also only a factor for the selected viscosity (again, 1=no effect). - For objects that are enabled for fluidsim, a new IPO type shows up. Inflow objects can use the velocity channels to animate the inflow. Obstacles, in/outflow objects can be switched on (Active IPO>0) and off (<0) during the simulation. - Movement, rotation and scaling of those 3 types is exported from the normal Blender channels (Loc,dLoc,etc.). Particles: - This is still experimental, so it might be deactivated for a release... It should at some point be used to model smaller splashes, depending on the the realworld size and the particle generation settings particles are generated during simulation (stored in _particles_X.gz files). - These are loaded by enabling the particle field for an arbitrary object, which should be given a halo material. For each frame, similar to the mesh loading, the particle system them loads the simulated particle positions. - For rendering, I "abused" the part->rt field - I couldnt find any use for it in the code and it seems to work fine. The fluidsim particles store their size there. Rendering: - The fluidims particles use scaled sizes and alpha values to give a more varied appearance. In convertblender.c fluidsim particle systems use the p->rt field to scale up the size and down the alpha of "smaller particles". Setting the influence fields in the fluidims settings to 0 gives equally sized particles with same alpha everywhere. Higher values cause larger differences. - Smoothed normals: for unmodified fluid meshes (e.g. no subdivision) the normals computed by the solver are used. This is basically done by switching off the normal recalculation in convertblender.c (the function calc_fluidsimnormals handles other mesh inits instead of calc_vertexnormals). This could also be used to e.g. modify mesh normals in a modifier... - Another change is that fluidsim meshes load the velocities computed during the simulation for image based motion blur. This is inited in load_fluidsimspeedvectors for the vector pass (they're loaded during the normal load in DerivedMesh readBobjgz). Generation and loading can be switched off in the settings. Vector pass currently loads the fluidism meshes 3 times, so this should still be optimized. Examples: - smoothed normals versus normals from subdividing once: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_1smoothnorms.png http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_2subdivnorms.png - fluidsim particles, size/alpha influence 0: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_3particlesnorm.png size influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_4particlessize.png size & alpha influence 1: http://www10.informatik.uni-erlangen.de/~sinithue/temp/v060227_5particlesalpha.png - the standard drop with motion blur and particles: http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t2new.mpg (here's how it looks without http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t1old.mpg) - another inflow animation (moving, switched on/off) with a moving obstacle (and strong mblur :) http://www10.informatik.uni-erlangen.de/~sinithue/temp/elbeemupdate_t3ipos.mpg Things still to fix: - rotating & scaling domains causes wrong speed vectors - get rid of SDL code for threading, use pthreads as well? - update wiki documentation - cool effects for rendering would be photon maps for caustics, and motion blur for particles :)
2006-02-27 12:45:42 +01:00
*bbmesh = newmesh;
}
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00
}
- modified patch #4681, for scons compiling of the fluidsim can now be disabled with the flag: BF_NO_ELBEEM='true', e.g. for irix systems. (The number of ifdefs from the original patch was reduced, and the defines are now only necessary when elbeem is switched off.) - particle generation option is available again
2006-08-22 13:18:00 +02:00
#else // DISABLE_ELBEEM
/* dummy for mesh_calc_modifiers */
void loadFluidsimMesh(Object *srcob, int useRenderParams) {
}
#endif // DISABLE_ELBEEM
- popup menu now aborts by default - changed directory/prefix input (only 1 string instead of two, more similar to render output settings now) - changed reading/writing of surface files - slightly enhanced surface smoothness
2005-11-09 08:56:26 +01:00