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

2168 lines
60 KiB
C
Raw Normal View History

- 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 20:14:17 +00:00
#include "string.h"
- 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 07:25:43 +00:00
#include "stdarg.h"
- 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 02:44:59 +00:00
#include "math.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 20:14:17 +00: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 07:37:15 +00:00
#include "BLI_blenlib.h"
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
#include "BLI_rand.h"
- 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-10 22:05:52 +00:00
#include "BLI_arithb.h"
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
#include "BLI_edgehash.h"
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00: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 20:14:17 +00:00
#include "MEM_guardedalloc.h"
Another option for more Armature deform control; The "Use VGroup" or "Use Envelope" options now are in Modifier Panel for Armature deform. If Modifiers are in use, they override the Armature settings for it. (Cannot get rid of the Armature panel options yet, since Blender still allows parenting to be deforming too, which is displayed as a Virtual modifier now) This now allows to - for example - make a Envelope deform on a Lattice, and have same Armature use vertexgroups on Mesh. Next; vertexgroup option for Lattice & Curve deform
2005-10-20 16:31:46 +00:00
#include "DNA_armature_types.h"
#include "DNA_effect_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 20:14:17 +00:00
#include "DNA_mesh_types.h"
#include "DNA_meshdata_types.h"
#include "DNA_modifier_types.h"
#include "DNA_object_types.h"
- switch to using softbody modifier, controls enabling but does not have variables, these are still in same place. enable button automatically makes/enables modifier. - changed hook to hook modifier conversion to happen on direct link, required to make sure we don't forget to free any memory for files saved with 2.38 that have hooks. - update modifier interface to enforce modifiers with the require-original- data flag to not move beyond deforming modifiers. - enforce only one softbody modifier allowed NOTE: Once again, no modifier stack for lattice yet means softbody for lattice does not work atm.
2005-08-11 02:23:52 +00:00
#include "DNA_object_force.h"
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
#include "DNA_scene_types.h"
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
#include "DNA_curve_types.h"
Another option for more Armature deform control; The "Use VGroup" or "Use Envelope" options now are in Modifier Panel for Armature deform. If Modifiers are in use, they override the Armature settings for it. (Cannot get rid of the Armature panel options yet, since Blender still allows parenting to be deforming too, which is displayed as a Virtual modifier now) This now allows to - for example - make a Envelope deform on a Lattice, and have same Armature use vertexgroups on Mesh. Next; vertexgroup option for Lattice & Curve deform
2005-10-20 16:31:46 +00: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 07:37:15 +00:00
#include "BLI_editVert.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 20:14:17 +00:00
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
#include "MTC_matrixops.h"
#include "MTC_vectorops.h"
#include "BKE_anim.h"
- 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 07:25:43 +00:00
#include "BKE_bad_level_calls.h"
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
#include "BKE_global.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 20:14:17 +00:00
#include "BKE_utildefines.h"
#include "BKE_DerivedMesh.h"
Saturday morning first cup of coffee hack (yeah, its a late morning) - fun for the whole family, boolean mesh modifier... doesn't work with layered modifiers yet (just uses base mesh), although may god have mercy on your soul if you want to run boolean on a subsurf anyway - added displistmesh_add_edges This exposes a bug in boolean, apparently the output is somehow random (hash on alloc'd pointer value perhaps) which is sortof lame. It also makes more apparent the desire for some level of control over dep graph evaluation during editmode (at the moment dep graph is reevaluated for a mesh object in editmode, but since mesh changes are on editmesh other objects don't really see any change, so it is a wasted recalc).
2005-09-03 17:22:29 +00:00
#include "BKE_booleanops.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 20:14:17 +00:00
#include "BKE_displist.h"
#include "BKE_modifier.h"
#include "BKE_lattice.h"
#include "BKE_subsurf.h"
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
#include "BKE_object.h"
#include "BKE_mesh.h"
- switch to using softbody modifier, controls enabling but does not have variables, these are still in same place. enable button automatically makes/enables modifier. - changed hook to hook modifier conversion to happen on direct link, required to make sure we don't forget to free any memory for files saved with 2.38 that have hooks. - update modifier interface to enforce modifiers with the require-original- data flag to not move beyond deforming modifiers. - enforce only one softbody modifier allowed NOTE: Once again, no modifier stack for lattice yet means softbody for lattice does not work atm.
2005-08-11 02:23:52 +00:00
#include "BKE_softbody.h"
- added ModifierTypeInfo.updateDepgraph function, responsible for building appropriate relations in dep graph (modifiers respond to scene changes correctly now) - update modifier buttons to trigger depgraph rebuild if needed
2005-07-19 23:04:34 +00:00
#include "depsgraph_private.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 20:14:17 +00: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 02:44:59 +00:00
#include "LOD_DependKludge.h"
#include "LOD_decimation.h"
- 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 20:30:33 +00:00
#include "CCGSubSurf.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 20:14:17 +00:00
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
/* helper function for modifiers - usage is of this is discouraged, but
avoids duplicate modifier code for DispListMesh and EditMesh */
DispListMesh *displistmesh_from_editmesh(EditMesh *em)
{
DispListMesh *outDLM = MEM_callocN(sizeof(*outDLM), "em_mod_dlm");
EditVert *eve, *preveve;
EditEdge *eed;
EditFace *efa;
int i;
for (i=0,eve=em->verts.first; eve; eve= eve->next)
eve->prev = (EditVert*) i++;
outDLM->totvert = BLI_countlist(&em->verts);
outDLM->totedge = BLI_countlist(&em->edges);
outDLM->totface = BLI_countlist(&em->faces);
outDLM->mvert = MEM_mallocN(sizeof(*outDLM->mvert)*outDLM->totvert,
"em_mod_mv");
outDLM->medge = MEM_mallocN(sizeof(*outDLM->medge)*outDLM->totedge,
"em_mod_med");
outDLM->mface = MEM_mallocN(sizeof(*outDLM->mface)*outDLM->totface,
"em_mod_mf");
/* Need to be able to mark loose edges */
for (eed=em->edges.first; eed; eed=eed->next) {
eed->f2 = 0;
}
for (efa=em->faces.first; efa; efa=efa->next) {
efa->e1->f2 = 1;
efa->e2->f2 = 1;
efa->e3->f2 = 1;
if (efa->e4) efa->e4->f2 = 1;
}
for (i=0,eve=em->verts.first; i<outDLM->totvert; i++,eve=eve->next) {
MVert *mv = &outDLM->mvert[i];
VECCOPY(mv->co, eve->co);
mv->mat_nr = 0;
mv->flag = ME_VERT_STEPINDEX;
}
for (i=0,eed=em->edges.first; i<outDLM->totedge; i++,eed=eed->next) {
MEdge *med = &outDLM->medge[i];
med->v1 = (int) eed->v1->prev;
med->v2 = (int) eed->v2->prev;
med->crease = (unsigned char) (eed->crease*255.0f);
med->flag = ME_EDGEDRAW|ME_EDGERENDER|ME_EDGE_STEPINDEX;
if (eed->seam) med->flag |= ME_SEAM;
if (!eed->f2) med->flag |= ME_LOOSEEDGE;
}
for (i=0,efa=em->faces.first; i<outDLM->totface; i++,efa=efa->next) {
MFace *mf = &outDLM->mface[i];
mf->v1 = (int) efa->v1->prev;
mf->v2 = (int) efa->v2->prev;
mf->v3 = (int) efa->v3->prev;
mf->v4 = efa->v4?(int) efa->v4->prev:0;
mf->mat_nr = efa->mat_nr;
mf->flag = efa->flag|ME_FACE_STEPINDEX;
test_index_face(mf, NULL, NULL, efa->v4?4:3);
}
for (preveve=NULL, eve=em->verts.first; eve; preveve=eve, eve= eve->next)
eve->prev = preveve;
return outDLM;
}
- 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 20:30:33 +00: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 20:14:17 +00:00
static int noneModifier_isDisabled(ModifierData *md)
{
return 1;
}
/* Curve */
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
static void curveModifier_copyData(ModifierData *md, ModifierData *target)
{
CurveModifierData *cmd = (CurveModifierData*) md;
CurveModifierData *tcmd = (CurveModifierData*) target;
tcmd->object = cmd->object;
}
- 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 20:14:17 +00:00
static int curveModifier_isDisabled(ModifierData *md)
{
CurveModifierData *cmd = (CurveModifierData*) md;
return !cmd->object;
}
- 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-10 22:05:52 +00:00
static void curveModifier_foreachObjectLink(ModifierData *md, Object *ob, void (*walk)(void *userData, Object *ob, Object **obpoin), void *userData)
{
CurveModifierData *cmd = (CurveModifierData*) md;
walk(userData, ob, &cmd->object);
}
- added ModifierTypeInfo.updateDepgraph function, responsible for building appropriate relations in dep graph (modifiers respond to scene changes correctly now) - update modifier buttons to trigger depgraph rebuild if needed
2005-07-19 23:04:34 +00:00
static void curveModifier_updateDepgraph(ModifierData *md, DagForest *forest, Object *ob, DagNode *obNode)
{
CurveModifierData *cmd = (CurveModifierData*) md;
if (cmd->object) {
DagNode *curNode = dag_get_node(forest, cmd->object);
dag_add_relation(forest, curNode, obNode, DAG_RL_DATA_DATA|DAG_RL_OB_DATA);
}
}
- 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 07:37:15 +00:00
static void curveModifier_deformVerts(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int numVerts)
{
CurveModifierData *cmd = (CurveModifierData*) md;
Curve and Lattice deform Modifiers now accept optional Vertex Group name to finetune deform further as well. Note that curve deform requires object buttons 'track' and 'up' axes set properly. Curve deform can twist/flip a lot, making Vertex Group based deform hard to set up.
2005-10-20 18:52:29 +00:00
curve_deform_verts(cmd->object, ob, vertexCos, numVerts, cmd->name);
- 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 07:37:15 +00:00
}
static void curveModifier_deformVertsEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3], int 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 20:14:17 +00:00
{
- get rid of unused object_deform_curve - some tweaks to modifier UI thanks to Bart (aligning buttons)
2005-08-15 00:53:51 +00:00
curveModifier_deformVerts(md, ob, NULL, vertexCos, 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 20:14:17 +00:00
}
/* Lattice */
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
static void latticeModifier_copyData(ModifierData *md, ModifierData *target)
{
LatticeModifierData *lmd = (LatticeModifierData*) md;
LatticeModifierData *tlmd = (LatticeModifierData*) target;
tlmd->object = lmd->object;
}
- 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 20:14:17 +00:00
static int latticeModifier_isDisabled(ModifierData *md)
{
LatticeModifierData *lmd = (LatticeModifierData*) md;
return !lmd->object;
}
- 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-10 22:05:52 +00:00
static void latticeModifier_foreachObjectLink(ModifierData *md, Object *ob, void (*walk)(void *userData, Object *ob, Object **obpoin), void *userData)
{
LatticeModifierData *lmd = (LatticeModifierData*) md;
walk(userData, ob, &lmd->object);
}
- added ModifierTypeInfo.updateDepgraph function, responsible for building appropriate relations in dep graph (modifiers respond to scene changes correctly now) - update modifier buttons to trigger depgraph rebuild if needed
2005-07-19 23:04:34 +00:00
static void latticeModifier_updateDepgraph(ModifierData *md, DagForest *forest, Object *ob, DagNode *obNode)
{
LatticeModifierData *lmd = (LatticeModifierData*) md;
if (lmd->object) {
DagNode *latNode = dag_get_node(forest, lmd->object);
dag_add_relation(forest, latNode, obNode, DAG_RL_DATA_DATA|DAG_RL_OB_DATA);
}
}
- 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 07:37:15 +00:00
static void latticeModifier_deformVerts(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int numVerts)
{
LatticeModifierData *lmd = (LatticeModifierData*) md;
Curve and Lattice deform Modifiers now accept optional Vertex Group name to finetune deform further as well. Note that curve deform requires object buttons 'track' and 'up' axes set properly. Curve deform can twist/flip a lot, making Vertex Group based deform hard to set up.
2005-10-20 18:52:29 +00:00
lattice_deform_verts(lmd->object, ob, vertexCos, numVerts, lmd->name);
- 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 07:37:15 +00:00
}
static void latticeModifier_deformVertsEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3], int 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 20:14:17 +00:00
{
- get rid of unused object_deform_curve - some tweaks to modifier UI thanks to Bart (aligning buttons)
2005-08-15 00:53:51 +00:00
latticeModifier_deformVerts(md, ob, NULL, vertexCos, 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 20:14:17 +00:00
}
/* Subsurf */
- 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 20:30:33 +00:00
static void subsurfModifier_initData(ModifierData *md)
- 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 20:14:17 +00: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 20:30:33 +00:00
SubsurfModifierData *smd = (SubsurfModifierData*) md;
- 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 20:14:17 +00:00
smd->levels = 1;
smd->renderLevels = 2;
Apply Subsurf to UV's. This fixes most of the UV distortion issues with subsurf. Near seams however there might still be some distortion, but this should at least not be worse than before. Subsurf UV is enabled by default on new meshes, and can be enabled in the modifier panel for existing ones. Before and after: http://users.pandora.be/blendix/notsmooth.png http://users.pandora.be/blendix/smooth.png
2006-01-10 11:36:57 +00:00
smd->flags |= eSubsurfModifierFlag_SubsurfUv;
- 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 20:14:17 +00:00
}
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
static void subsurfModifier_copyData(ModifierData *md, ModifierData *target)
{
SubsurfModifierData *smd = (SubsurfModifierData*) md;
SubsurfModifierData *tsmd = (SubsurfModifierData*) target;
tsmd->flags = smd->flags;
tsmd->levels = smd->levels;
tsmd->renderLevels = smd->renderLevels;
tsmd->subdivType = smd->subdivType;
}
- 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 20:30:33 +00:00
static void subsurfModifier_freeData(ModifierData *md)
{
SubsurfModifierData *smd = (SubsurfModifierData*) md;
if (smd->mCache) {
ccgSubSurf_free(smd->mCache);
}
- 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 07:37:15 +00:00
if (smd->emCache) {
ccgSubSurf_free(smd->emCache);
}
- 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 20:30:33 +00: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 07:37:15 +00:00
static void *subsurfModifier_applyModifier(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int useRenderParams, int isFinalCalc)
- 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 20:14:17 +00:00
{
- add comments to BKE_DerivedMesh.h about which functions are called in editmode - gcc warning fixes - start work to make CCGDerivedMesh able to run in object mode (hint: more speed improvements) - fix modifier move down tooltip
2005-07-21 21:19:38 +00:00
DerivedMesh *dm = derivedData;
- 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 20:14:17 +00:00
SubsurfModifierData *smd = (SubsurfModifierData*) md;
- 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 04:44:02 +00:00
Mesh *me = ob->data;
- 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 20:14:17 +00:00
if (dm) {
- 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 02:30:29 +00:00
DispListMesh *dlm = dm->convertToDispListMesh(dm, 0);
- 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 20:14:17 +00:00
int i;
if (vertexCos) {
int numVerts = dm->getNumVerts(dm);
for (i=0; i<numVerts; i++) {
VECCOPY(dlm->mvert[i].co, vertexCos[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 07:37:15 +00:00
dm = subsurf_make_derived_from_mesh(me, dlm, smd, useRenderParams, NULL, isFinalCalc);
return dm;
} else {
return subsurf_make_derived_from_mesh(me, NULL, smd, useRenderParams, vertexCos, isFinalCalc);
}
}
static void *subsurfModifier_applyModifierEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3])
{
EditMesh *em = editData;
DerivedMesh *dm = derivedData;
SubsurfModifierData *smd = (SubsurfModifierData*) md;
if (dm) {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
DispListMesh *dlm = dm->convertToDispListMesh(dm, 0);
- 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 05:42:03 +00: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 03:08:23 +00:00
dm = subsurf_make_derived_from_dlm_em(dlm, smd, vertexCos);
- 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 05:42:03 +00:00
return 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 20:14:17 +00:00
} 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 07:37:15 +00:00
return subsurf_make_derived_from_editmesh(em, smd, vertexCos);
- 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 20:14:17 +00:00
}
}
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
/* Build */
- 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 20:30:33 +00:00
static void buildModifier_initData(ModifierData *md)
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00: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 20:30:33 +00:00
BuildModifierData *bmd = (BuildModifierData*) md;
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
bmd->start = 1.0;
bmd->length = 100.0;
}
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
static void buildModifier_copyData(ModifierData *md, ModifierData *target)
{
BuildModifierData *bmd = (BuildModifierData*) md;
BuildModifierData *tbmd = (BuildModifierData*) target;
tbmd->start = bmd->start;
tbmd->length = bmd->length;
tbmd->randomize = bmd->randomize;
tbmd->seed = bmd->seed;
}
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
static int buildModifier_dependsOnTime(ModifierData *md)
{
return 1;
}
- 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 07:37:15 +00:00
static void *buildModifier_applyModifier(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int useRenderParams, int isFinalCalc)
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
{
- add comments to BKE_DerivedMesh.h about which functions are called in editmode - gcc warning fixes - start work to make CCGDerivedMesh able to run in object mode (hint: more speed improvements) - fix modifier move down tooltip
2005-07-21 21:19:38 +00:00
DerivedMesh *dm = derivedData;
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
BuildModifierData *bmd = (BuildModifierData*) md;
DispListMesh *dlm=NULL, *ndlm = MEM_callocN(sizeof(*ndlm), "build_dlm");
MVert *mvert;
MEdge *medge;
MFace *mface;
MCol *mcol;
TFace *tface;
int totvert, totedge, totface;
int i,j;
float frac;
if (dm) {
- 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 02:30:29 +00:00
dlm = dm->convertToDispListMesh(dm, 1);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
mvert = dlm->mvert;
medge = dlm->medge;
mface = dlm->mface;
mcol = dlm->mcol;
tface = dlm->tface;
totvert = dlm->totvert;
totedge = dlm->totedge;
totface = dlm->totface;
} else {
- 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 04:44:02 +00:00
Mesh *me = ob->data;
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
mvert = me->mvert;
medge = me->medge;
mface = me->mface;
mcol = me->mcol;
tface = me->tface;
totvert = me->totvert;
totedge = me->totedge;
totface = me->totface;
}
if (ob) {
frac = bsystem_time(ob, 0, (float)G.scene->r.cfra, bmd->start-1.0f)/bmd->length;
} else {
frac = G.scene->r.cfra - bmd->start/bmd->length;
}
CLAMP(frac, 0.0, 1.0);
ndlm->totface = totface*frac;
ndlm->totedge = totedge*frac;
if (ndlm->totface) {
ndlm->mvert = MEM_mallocN(sizeof(*ndlm->mvert)*totvert, "build_mvert");
memcpy(ndlm->mvert, mvert, sizeof(*mvert)*totvert);
for (i=0; i<totvert; i++) {
- orco fix for build effect, didn't copy input vertex cos over (duh!)
2005-07-20 04:56:15 +00:00
if (vertexCos)
VECCOPY(ndlm->mvert[i].co, vertexCos[i]);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
ndlm->mvert[i].flag = 0;
}
if (bmd->randomize) {
ndlm->mface = MEM_dupallocN(mface);
BLI_array_randomize(ndlm->mface, sizeof(*mface), totface, bmd->seed);
if (tface) {
ndlm->tface = MEM_dupallocN(tface);
BLI_array_randomize(ndlm->tface, sizeof(*tface), totface, bmd->seed);
} else if (mcol) {
ndlm->mcol = MEM_dupallocN(mcol);
BLI_array_randomize(ndlm->mcol, sizeof(*mcol)*4, totface, bmd->seed);
}
} else {
ndlm->mface = MEM_mallocN(sizeof(*ndlm->mface)*ndlm->totface, "build_mf");
memcpy(ndlm->mface, mface, sizeof(*mface)*ndlm->totface);
if (tface) {
ndlm->tface = MEM_mallocN(sizeof(*ndlm->tface)*ndlm->totface, "build_tf");
memcpy(ndlm->tface, tface, sizeof(*tface)*ndlm->totface);
} else if (mcol) {
ndlm->mcol = MEM_mallocN(sizeof(*ndlm->mcol)*4*ndlm->totface, "build_mcol");
memcpy(ndlm->mcol, mcol, sizeof(*mcol)*4*ndlm->totface);
}
}
for (i=0; i<ndlm->totface; i++) {
MFace *mf = &ndlm->mface[i];
ndlm->mvert[mf->v1].flag = 1;
ndlm->mvert[mf->v2].flag = 1;
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
ndlm->mvert[mf->v3].flag = 1;
if (mf->v4) ndlm->mvert[mf->v4].flag = 1;
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
}
/* Store remapped indices in *((int*) mv->no) */
ndlm->totvert = 0;
for (i=0; i<totvert; i++) {
MVert *mv = &ndlm->mvert[i];
if (mv->flag)
*((int*) mv->no) = ndlm->totvert++;
}
/* Remap face vertex indices */
for (i=0; i<ndlm->totface; i++) {
MFace *mf = &ndlm->mface[i];
mf->v1 = *((int*) ndlm->mvert[mf->v1].no);
mf->v2 = *((int*) ndlm->mvert[mf->v2].no);
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
mf->v3 = *((int*) ndlm->mvert[mf->v3].no);
if (mf->v4) mf->v4 = *((int*) ndlm->mvert[mf->v4].no);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
}
/* Copy in all edges that have both vertices (remap in process) */
if (totedge) {
ndlm->totedge = 0;
ndlm->medge = MEM_mallocN(sizeof(*ndlm->medge)*totedge, "build_med");
for (i=0; i<totedge; i++) {
MEdge *med = &medge[i];
if (ndlm->mvert[med->v1].flag && ndlm->mvert[med->v2].flag) {
MEdge *nmed = &ndlm->medge[ndlm->totedge++];
memcpy(nmed, med, sizeof(*med));
nmed->v1 = *((int*) ndlm->mvert[nmed->v1].no);
nmed->v2 = *((int*) ndlm->mvert[nmed->v2].no);
}
}
}
/* Collapse vertex array to remove unused verts */
for(i=j=0; i<totvert; i++) {
MVert *mv = &ndlm->mvert[i];
if (mv->flag) {
if (j!=i)
memcpy(&ndlm->mvert[j], mv, sizeof(*mv));
j++;
}
}
} else if (ndlm->totedge) {
ndlm->mvert = MEM_mallocN(sizeof(*ndlm->mvert)*totvert, "build_mvert");
memcpy(ndlm->mvert, mvert, sizeof(*mvert)*totvert);
for (i=0; i<totvert; i++) {
- orco fix for build effect, didn't copy input vertex cos over (duh!)
2005-07-20 04:56:15 +00:00
if (vertexCos)
VECCOPY(ndlm->mvert[i].co, vertexCos[i]);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
ndlm->mvert[i].flag = 0;
}
if (bmd->randomize) {
ndlm->medge = MEM_dupallocN(medge);
BLI_array_randomize(ndlm->medge, sizeof(*medge), totedge, bmd->seed);
} else {
ndlm->medge = MEM_mallocN(sizeof(*ndlm->medge)*ndlm->totedge, "build_mf");
memcpy(ndlm->medge, medge, sizeof(*medge)*ndlm->totedge);
}
for (i=0; i<ndlm->totedge; i++) {
MEdge *med = &ndlm->medge[i];
ndlm->mvert[med->v1].flag = 1;
ndlm->mvert[med->v2].flag = 1;
}
/* Store remapped indices in *((int*) mv->no) */
ndlm->totvert = 0;
for (i=0; i<totvert; i++) {
MVert *mv = &ndlm->mvert[i];
if (mv->flag)
*((int*) mv->no) = ndlm->totvert++;
}
/* Remap edge vertex indices */
for (i=0; i<ndlm->totedge; i++) {
MEdge *med = &ndlm->medge[i];
med->v1 = *((int*) ndlm->mvert[med->v1].no);
med->v2 = *((int*) ndlm->mvert[med->v2].no);
}
/* Collapse vertex array to remove unused verts */
for(i=j=0; i<totvert; i++) {
MVert *mv = &ndlm->mvert[i];
if (mv->flag) {
if (j!=i)
memcpy(&ndlm->mvert[j], mv, sizeof(*mv));
j++;
}
}
} else {
ndlm->totvert = totvert*frac;
- 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 20:30:33 +00:00
if (bmd->randomize) {
ndlm->mvert = MEM_dupallocN(mvert);
BLI_array_randomize(ndlm->mvert, sizeof(*mvert), totvert, bmd->seed);
} else {
ndlm->mvert = MEM_mallocN(sizeof(*ndlm->mvert)*ndlm->totvert, "build_mvert");
memcpy(ndlm->mvert, mvert, sizeof(*mvert)*ndlm->totvert);
}
- orco fix for build effect, didn't copy input vertex cos over (duh!)
2005-07-20 04:56:15 +00:00
if (vertexCos) {
for (i=0; i<ndlm->totvert; i++) {
VECCOPY(ndlm->mvert[i].co, vertexCos[i]);
}
}
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
}
if (dlm) displistmesh_free(dlm);
mesh_calc_normals(ndlm->mvert, ndlm->totvert, ndlm->mface, ndlm->totface, &ndlm->nors);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
return derivedmesh_from_displistmesh(ndlm, NULL);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
}
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
/* Array */
/* Array modifier: duplicates the object multiple times along an axis
*/
static void arrayModifier_initData(ModifierData *md)
{
ArrayModifierData *amd = (ArrayModifierData*) md;
/* default to 2 duplicates distributed along the x-axis by an
offset of 1 object-width
*/
amd->curve_ob = amd->offset_ob = NULL;
amd->count = 2;
amd->offset[0] = amd->offset[1] = amd->offset[2] = 0;
amd->scale[0] = 1;
amd->scale[1] = amd->scale[2] = 0;
amd->length = 0;
amd->merge_dist = 0.01;
amd->fit_type = MOD_ARR_FIXEDCOUNT;
amd->offset_type = MOD_ARR_OFF_RELATIVE;
amd->flags = 0;
}
static void arrayModifier_copyData(ModifierData *md, ModifierData *target)
{
ArrayModifierData *amd = (ArrayModifierData*) md;
ArrayModifierData *tamd = (ArrayModifierData*) target;
tamd->curve_ob = amd->curve_ob;
tamd->offset_ob = amd->offset_ob;
tamd->count = amd->count;
VECCOPY(tamd->offset, amd->offset);
VECCOPY(tamd->scale, amd->scale);
tamd->length = amd->length;
tamd->merge_dist = amd->merge_dist;
tamd->fit_type = amd->fit_type;
tamd->offset_type = amd->offset_type;
tamd->flags = amd->flags;
}
static void arrayModifier_foreachObjectLink(ModifierData *md,
Object *ob,
void (*walk)(void *userData, Object *ob, Object **obpoin),
void *userData)
{
ArrayModifierData *amd = (ArrayModifierData*) md;
walk(userData, ob, &amd->curve_ob);
walk(userData, ob, &amd->offset_ob);
}
static void arrayModifier_updateDepgraph(ModifierData *md,
DagForest *forest,
Object *ob,
DagNode *obNode)
{
ArrayModifierData *amd = (ArrayModifierData*) md;
if (amd->curve_ob) {
DagNode *curNode = dag_get_node(forest, amd->curve_ob);
dag_add_relation(forest, curNode, obNode,
DAG_RL_DATA_DATA|DAG_RL_OB_DATA);
}
if (amd->offset_ob) {
DagNode *curNode = dag_get_node(forest, amd->offset_ob);
dag_add_relation(forest, curNode, obNode,
DAG_RL_DATA_DATA|DAG_RL_OB_DATA);
}
}
float displistmesh_width(DispListMesh *dlm, int axis)
{
int i;
float min_co, max_co;
MVert *mv;
/* if there are no vertices, width is 0 */
if(dlm->totvert == 0) return 0;
/* find the minimum and maximum coordinates on the desired axis */
min_co = max_co = dlm->mvert[0].co[axis];
for (i=1; i < dlm->totvert; i++) {
mv = &dlm->mvert[i];
if(mv->co[axis] < min_co) min_co = mv->co[axis];
if(mv->co[axis] > max_co) max_co = mv->co[axis];
}
return max_co - min_co;
}
typedef struct IndexMapEntry {
/* the new vert index that this old vert index maps to */
int new;
/* -1 if this vert isn't merged, otherwise the old vert index it
* should be replaced with
*/
int merge;
/* 1 if this vert's first copy is merged with the last copy of its
* merge target, otherwise 0
*/
short merge_final;
} IndexMapEntry;
static int calc_mapping(IndexMapEntry *indexMap, int oldVert, int copy)
{
int newVert;
if(indexMap[oldVert].merge < 0) {
newVert = indexMap[oldVert].new + copy + 1;
} else if(indexMap[oldVert].merge == oldVert) {
/* This vert was merged with itself */
newVert = indexMap[oldVert].new;
} else {
/* This vert wasn't merged with itself, so increment vert number. */
newVert = indexMap[indexMap[oldVert].merge].new + copy;
}
return newVert;
}
static DispListMesh *arrayModifier_doArray(ArrayModifierData *amd,
Object *ob, DispListMesh *inDLM,
float (*vertexCos)[3],
int initFlags)
{
int i, j;
/* offset matrix */
float offset[4][4];
float final_offset[4][4];
float tmp_mat[4][4];
float length = amd->length;
int count = amd->count;
DispListMesh *dlm = MEM_callocN(sizeof(*dlm), "array_dlm");
IndexMapEntry *indexMap;
EdgeHash *edges;
MTC_Mat4One(offset);
if(amd->offset_type & MOD_ARR_OFF_CONST)
VecAddf(offset[3], offset[3], amd->offset);
if(amd->offset_type & MOD_ARR_OFF_RELATIVE) {
for(j = 0; j < 3; j++)
offset[3][j] += amd->scale[j] * displistmesh_width(inDLM, j);
}
if((amd->offset_type & MOD_ARR_OFF_OBJ) && (amd->offset_ob)) {
float obinv[4][4];
float result_mat[4][4];
if(ob)
MTC_Mat4Invert(obinv, ob->obmat);
else
MTC_Mat4One(obinv);
MTC_Mat4MulSerie(result_mat, offset,
obinv, amd->offset_ob->obmat,
NULL, NULL, NULL, NULL, NULL);
MTC_Mat4CpyMat4(offset, result_mat);
}
if(amd->fit_type == MOD_ARR_FITCURVE && amd->curve_ob) {
Curve *cu = amd->curve_ob->data;
if(cu) {
if(!cu->path)
calc_curvepath(amd->curve_ob);
if(cu->path)
length = cu->path->totdist;
}
}
/* calculate the maximum number of copies which will fit within the
prescribed length */
if(amd->fit_type == MOD_ARR_FITLENGTH
|| amd->fit_type == MOD_ARR_FITCURVE) {
float dist = sqrt(MTC_dot3Float(offset[3], offset[3]));
if(dist != 0)
/* this gives length = first copy start to last copy end
add a tiny offset for floating point rounding errors */
count = (length + 0.00001) / dist;
else
/* if the offset has no translation, just make one copy */
count = 1;
}
if(count < 1)
count = 1;
dlm->totvert = dlm->totedge = dlm->totface = 0;
indexMap = MEM_callocN(sizeof(*indexMap)*inDLM->totvert, "indexmap");
/* allocate memory for count duplicates (including original) */
dlm->mvert = MEM_callocN(sizeof(*dlm->mvert)*inDLM->totvert*count,
"dlm_mvert");
dlm->mface = MEM_callocN(sizeof(*dlm->mface)*inDLM->totface*count,
"dlm_mface");
if (inDLM->medge)
dlm->medge = MEM_callocN(sizeof(*dlm->medge)*inDLM->totedge*count,
"dlm_medge");
if (inDLM->tface)
dlm->tface = MEM_callocN(sizeof(*dlm->tface)*inDLM->totface*count,
"dlm_tface");
if (inDLM->mcol)
dlm->mcol = MEM_callocN(sizeof(*dlm->mcol)*inDLM->totface*4*count,
"dlm_mcol");
/* calculate the offset matrix of the final copy (for merging) */
MTC_Mat4One(final_offset);
for(j=0; j < count - 1; j++) {
MTC_Mat4MulMat4(tmp_mat, final_offset, offset);
MTC_Mat4CpyMat4(final_offset, tmp_mat);
}
for (i=0; i<inDLM->totvert; i++) {
MVert *inMV = &inDLM->mvert[i];
MVert *mv = &dlm->mvert[dlm->totvert++];
MVert *mv2;
float co[3];
*mv = *inMV;
if (vertexCos) {
VECCOPY(mv->co, vertexCos[i]);
}
if (initFlags) mv->flag |= ME_VERT_STEPINDEX;
indexMap[i].new = dlm->totvert-1;
indexMap[i].merge = -1; /* default to no merge */
indexMap[i].merge_final = 0; /* default to no merge */
VECCOPY(co, mv->co);
/* Attempts to merge verts from one duplicate with verts from the
* next duplicate which are closer than amd->merge_dist.
* Only the first such vert pair is merged.
* If verts are merged in the first duplicate pair, they are merged
* in all pairs.
*/
if((count > 1) && (amd->flags & MOD_ARR_MERGE)) {
float tmp_co[3];
VECCOPY(tmp_co, mv->co);
MTC_Mat4MulVecfl(offset, tmp_co);
for(j = 0; j < inDLM->totvert; j++) {
inMV = &inDLM->mvert[j];
/* if this vert is within merge limit, merge */
if(VecLenCompare(tmp_co, inMV->co, amd->merge_dist)) {
indexMap[i].merge = j;
/* test for merging with final copy of merge target */
if(amd->flags & MOD_ARR_MERGEFINAL) {
inMV = &inDLM->mvert[i];
VECCOPY(tmp_co, inDLM->mvert[j].co);
MTC_Mat4MulVecfl(final_offset, tmp_co);
if(VecLenCompare(tmp_co, inMV->co, amd->merge_dist))
indexMap[i].merge_final = 1;
}
break;
}
}
}
/* if no merging, generate copies of this vert */
if(indexMap[i].merge < 0) {
for(j=0; j < count - 1; j++) {
mv2 = &dlm->mvert[dlm->totvert++];
*mv2 = *mv;
MTC_Mat4MulVecfl(offset, co);
VECCOPY(mv2->co, co);
mv2->flag &= ~ME_VERT_STEPINDEX;
}
} else if(indexMap[i].merge != i && indexMap[i].merge_final) {
/* if this vert is not merging with itself, and it is merging
* with the final copy of its merge target, remove the first copy
*/
dlm->totvert--;
}
}
/* make a hashtable so we can avoid duplicate edges from merging */
edges = BLI_edgehash_new();
for (i=0; i<inDLM->totedge; i++) {
MEdge *inMED = &inDLM->medge[i];
MEdge med;
MEdge *med2;
int vert1, vert2;
med = *inMED;
med.v1 = indexMap[inMED->v1].new;
med.v2 = indexMap[inMED->v2].new;
/* if vertices are to be merged with the final copies of their
* merge targets, calculate that final copy
*/
if(indexMap[inMED->v1].merge_final) {
med.v1 = calc_mapping(indexMap, indexMap[inMED->v1].merge,
count - 2);
}
if(indexMap[inMED->v2].merge_final) {
med.v2 = calc_mapping(indexMap, indexMap[inMED->v2].merge,
count - 2);
}
if (initFlags) {
med.flag |= ME_EDGEDRAW|ME_EDGERENDER|ME_EDGE_STEPINDEX;
}
if(!BLI_edgehash_haskey(edges, med.v1, med.v2)) {
dlm->medge[dlm->totedge++] = med;
BLI_edgehash_insert(edges, med.v1, med.v2, NULL);
}
for(j=0; j < count - 1; j++)
{
vert1 = calc_mapping(indexMap, inMED->v1, j);
vert2 = calc_mapping(indexMap, inMED->v2, j);
/* avoid duplicate edges */
if(!BLI_edgehash_haskey(edges, vert1, vert2)) {
med2 = &dlm->medge[dlm->totedge++];
*med2 = med;
med2->v1 = vert1;
med2->v2 = vert2;
med2->flag &= ~ME_EDGE_STEPINDEX;
BLI_edgehash_insert(edges, med2->v1, med2->v2, NULL);
}
}
}
/* don't need the hashtable any more */
BLI_edgehash_free(edges, NULL);
for (i=0; i<inDLM->totface; i++) {
MFace *inMF = &inDLM->mface[i];
MFace *mf = &dlm->mface[dlm->totface++];
MFace *mf2;
TFace *tf = NULL;
MCol *mc = NULL;
*mf = *inMF;
mf->v1 = indexMap[inMF->v1].new;
mf->v2 = indexMap[inMF->v2].new;
mf->v3 = indexMap[inMF->v3].new;
mf->v4 = indexMap[inMF->v4].new;
/* if vertices are to be merged with the final copies of their
* merge targets, calculate that final copy
*/
if(indexMap[inMF->v1].merge_final)
mf->v1 = calc_mapping(indexMap, indexMap[inMF->v1].merge, count-2);
if(indexMap[inMF->v2].merge_final)
mf->v2 = calc_mapping(indexMap, indexMap[inMF->v2].merge, count-2);
if(indexMap[inMF->v3].merge_final)
mf->v3 = calc_mapping(indexMap, indexMap[inMF->v3].merge, count-2);
if(indexMap[inMF->v4].merge_final)
mf->v4 = calc_mapping(indexMap, indexMap[inMF->v4].merge, count-2);
if (initFlags) mf->flag |= ME_FACE_STEPINDEX;
if (inDLM->tface) {
TFace *inTF = &inDLM->tface[i];
TFace *tf = &dlm->tface[dlm->totface-1];
*tf = *inTF;
} else if (inDLM->mcol) {
MCol *inMC = &inDLM->mcol[i*4];
MCol *mc = &dlm->mcol[(dlm->totface-1)*4];
mc[0] = inMC[0];
mc[1] = inMC[1];
mc[2] = inMC[2];
mc[3] = inMC[3];
}
for(j=0; j < count - 1; j++)
{
mf2 = &dlm->mface[dlm->totface++];
*mf2 = *mf;
mf2->v1 = calc_mapping(indexMap, inMF->v1, j);
mf2->v2 = calc_mapping(indexMap, inMF->v2, j);
mf2->v3 = calc_mapping(indexMap, inMF->v3, j);
if (inMF->v4)
mf2->v4 = calc_mapping(indexMap, inMF->v4, j);
mf2->flag &= ~ME_FACE_STEPINDEX;
if (inDLM->tface) {
TFace *inTF = &inDLM->tface[i];
tf = &dlm->tface[dlm->totface-1];
*tf = *inTF;
} else if (inDLM->mcol) {
MCol *inMC = &inDLM->mcol[i*4];
mc = &dlm->mcol[(dlm->totface-1)*4];
mc[0] = inMC[0];
mc[1] = inMC[1];
mc[2] = inMC[2];
mc[3] = inMC[3];
}
test_index_face(mf2, mc, tf, inMF->v4?4:3);
/* if the face has fewer than 3 vertices, don't create it */
if(mf2->v3 == 0)
dlm->totface--;
}
}
MEM_freeN(indexMap);
return dlm;
}
static void *arrayModifier_applyModifier_internal(ModifierData *md,
Object *ob,
void *derivedData,
float (*vertexCos)[3],
int useRenderParams,
int isFinalCalc)
{
DerivedMesh *dm = derivedData;
ArrayModifierData *amd = (ArrayModifierData*) md;
DispListMesh *outDLM, *inDLM;
if (dm) {
inDLM = dm->convertToDispListMesh(dm, 1);
} else {
Mesh *me = ob->data;
inDLM = MEM_callocN(sizeof(*inDLM), "inDLM");
inDLM->dontFreeVerts = inDLM->dontFreeOther = 1;
inDLM->mvert = me->mvert;
inDLM->medge = me->medge;
inDLM->mface = me->mface;
inDLM->tface = me->tface;
inDLM->mcol = me->mcol;
inDLM->totvert = me->totvert;
inDLM->totedge = me->totedge;
inDLM->totface = me->totface;
}
outDLM = arrayModifier_doArray(amd, ob, inDLM, vertexCos, dm?0:1);
displistmesh_free(inDLM);
mesh_calc_normals(outDLM->mvert, outDLM->totvert, outDLM->mface,
outDLM->totface, &outDLM->nors);
return derivedmesh_from_displistmesh(outDLM, NULL);
}
static void *arrayModifier_applyModifier(ModifierData *md,
Object *ob,
void *derivedData,
float (*vertexCos)[3],
int useRenderParams,
int isFinalCalc)
{
return arrayModifier_applyModifier_internal(md, ob, derivedData,
vertexCos, 0, 1);
}
static void *arrayModifier_applyModifierEM(ModifierData *md,
Object *ob,
void *editData,
void *derivedData,
float (*vertexCos)[3])
{
if (derivedData) {
return arrayModifier_applyModifier_internal(md, ob, derivedData,
vertexCos, 0, 1);
} else {
ArrayModifierData *amd = (ArrayModifierData*) md;
DispListMesh *outDLM, *inDLM = displistmesh_from_editmesh(editData);
outDLM = arrayModifier_doArray(amd, ob, inDLM, vertexCos, 0);
displistmesh_free(inDLM);
mesh_calc_normals(outDLM->mvert, outDLM->totvert,
outDLM->mface, outDLM->totface, &outDLM->nors);
return derivedmesh_from_displistmesh(outDLM, NULL);
}
}
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
/* Mirror */
- 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 20:30:33 +00:00
static void mirrorModifier_initData(ModifierData *md)
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 20:30:33 +00:00
MirrorModifierData *mmd = (MirrorModifierData*) md;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
mmd->tolerance = 0.001;
}
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
static void mirrorModifier_copyData(ModifierData *md, ModifierData *target)
{
MirrorModifierData *mmd = (MirrorModifierData*) md;
MirrorModifierData *tmmd = (MirrorModifierData*) target;
tmmd->axis = mmd->axis;
tmmd->tolerance = mmd->tolerance;
}
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
static DispListMesh *mirrorModifier__doMirror(MirrorModifierData *mmd, DispListMesh *inDLM, float (*vertexCos)[3], int initFlags)
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 07:37:15 +00:00
int i, axis = mmd->axis;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
float tolerance = mmd->tolerance;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
DispListMesh *dlm = MEM_callocN(sizeof(*dlm), "mirror_dlm");
int (*indexMap)[2];
dlm->totvert = dlm->totedge = dlm->totface = 0;
indexMap = MEM_mallocN(sizeof(*indexMap)*inDLM->totvert, "indexmap");
dlm->mvert = MEM_callocN(sizeof(*dlm->mvert)*inDLM->totvert*2, "dlm_mvert");
dlm->mface = MEM_callocN(sizeof(*dlm->mface)*inDLM->totface*2, "dlm_mface");
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
if (inDLM->medge) dlm->medge = MEM_callocN(sizeof(*dlm->medge)*inDLM->totedge*2, "dlm_medge");
if (inDLM->tface) dlm->tface = MEM_callocN(sizeof(*dlm->tface)*inDLM->totface*2, "dlm_tface");
if (inDLM->mcol) dlm->mcol = MEM_callocN(sizeof(*dlm->mcol)*inDLM->totface*4*2, "dlm_mcol");
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
for (i=0; i<inDLM->totvert; i++) {
MVert *inMV = &inDLM->mvert[i];
MVert *mv = &dlm->mvert[dlm->totvert++];
int isShared = ABS(inMV->co[axis])<=tolerance;
/* Because the topology result (# of vertices) must be the same
- 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 05:42:03 +00:00
* if the mesh data is overridden by vertex cos, have to calc sharedness
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
* based on original coordinates. This is why we test before copy.
- 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 05:42:03 +00: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 03:08:23 +00:00
*mv = *inMV;
- bugfix, mirror modifier didn't copy deformed vertex cos for shared verts
2005-07-26 06:39:58 +00:00
if (vertexCos) {
VECCOPY(mv->co, vertexCos[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 03:08:23 +00:00
if (initFlags) mv->flag |= ME_VERT_STEPINDEX;
- bugfix, mirror modifier didn't copy deformed vertex cos for shared verts
2005-07-26 06:39:58 +00: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 03:08:23 +00:00
indexMap[i][0] = dlm->totvert-1;
indexMap[i][1] = !isShared;
- 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 05:42:03 +00:00
- bugfix, mirror modifier didn't copy deformed vertex cos for shared verts
2005-07-26 06:39:58 +00:00
if (isShared) {
- 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 07:37:15 +00:00
mv->co[axis] = 0;
Apply Subsurf to UV's. This fixes most of the UV distortion issues with subsurf. Near seams however there might still be some distortion, but this should at least not be worse than before. Subsurf UV is enabled by default on new meshes, and can be enabled in the modifier panel for existing ones. Before and after: http://users.pandora.be/blendix/notsmooth.png http://users.pandora.be/blendix/smooth.png
2006-01-10 11:36:57 +00:00
mv->flag |= ME_VERT_MERGED;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
MVert *mv2 = &dlm->mvert[dlm->totvert++];
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
*mv2 = *mv;
mv2->co[axis] = -mv2->co[axis];
mv2->flag &= ~ME_VERT_STEPINDEX;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
for (i=0; i<inDLM->totedge; i++) {
MEdge *inMED = &inDLM->medge[i];
MEdge *med = &dlm->medge[dlm->totedge++];
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
*med = *inMED;
med->v1 = indexMap[inMED->v1][0];
med->v2 = indexMap[inMED->v2][0];
- sillyness... added drawMappedEdges for mesh - revert to drawLooseEdges instead of general drawEdgesFlag - ditched TFace edge flags, done dynamically now which also means don't need to recalc surface on flag changes - added BLI_edgehash, guess what it does
2005-08-21 20:48:45 +00:00
if (initFlags) med->flag |= ME_EDGEDRAW|ME_EDGERENDER|ME_EDGE_STEPINDEX;
- 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 05:42:03 +00:00
- bug fix, mirror modifier could duplicate edges on boundary in certain cases
2005-08-20 20:04:32 +00:00
if (indexMap[inMED->v1][1] || indexMap[inMED->v2][1]) {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
MEdge *med2 = &dlm->medge[dlm->totedge++];
- 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 05:42:03 +00: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 03:08:23 +00:00
*med2 = *med;
- bug fix, mirror modifier could duplicate edges on boundary in certain cases
2005-08-20 20:04:32 +00:00
med2->v1 += indexMap[inMED->v1][1];
med2->v2 += indexMap[inMED->v2][1];
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
med2->flag &= ~ME_EDGE_STEPINDEX;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
for (i=0; i<inDLM->totface; i++) {
MFace *inMF = &inDLM->mface[i];
MFace *mf = &dlm->mface[dlm->totface++];
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
*mf = *inMF;
mf->v1 = indexMap[inMF->v1][0];
mf->v2 = indexMap[inMF->v2][0];
mf->v3 = indexMap[inMF->v3][0];
mf->v4 = indexMap[inMF->v4][0];
if (initFlags) mf->flag |= ME_FACE_STEPINDEX;
- 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 05:42:03 +00: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 03:08:23 +00:00
if (inDLM->tface) {
TFace *inTF = &inDLM->tface[i];
TFace *tf = &dlm->tface[dlm->totface-1];
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
*tf = *inTF;
} else if (inDLM->mcol) {
MCol *inMC = &inDLM->mcol[i*4];
MCol *mc = &dlm->mcol[(dlm->totface-1)*4];
- 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 05:42:03 +00: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 03:08:23 +00:00
mc[0] = inMC[0];
mc[1] = inMC[1];
mc[2] = inMC[2];
mc[3] = inMC[3];
}
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
if (indexMap[inMF->v1][1] || indexMap[inMF->v2][1] || indexMap[inMF->v3][1] || (mf->v4 && indexMap[inMF->v4][1])) {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
MFace *mf2 = &dlm->mface[dlm->totface++];
TFace *tf = NULL;
MCol *mc = NULL;
*mf2 = *mf;
- bug fix, mirror modifier could duplicate edges on boundary in certain cases
2005-08-20 20:04:32 +00:00
mf2->v1 += indexMap[inMF->v1][1];
mf2->v2 += indexMap[inMF->v2][1];
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
mf2->v3 += indexMap[inMF->v3][1];
- bug fix, mirror modifier could duplicate edges on boundary in certain cases
2005-08-20 20:04:32 +00:00
if (inMF->v4) mf2->v4 += indexMap[inMF->v4][1];
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
mf2->flag &= ~ME_FACE_STEPINDEX;
if (inDLM->tface) {
TFace *inTF = &inDLM->tface[i];
tf = &dlm->tface[dlm->totface-1];
*tf = *inTF;
} else if (inDLM->mcol) {
MCol *inMC = &inDLM->mcol[i*4];
mc = &dlm->mcol[(dlm->totface-1)*4];
mc[0] = inMC[0];
mc[1] = inMC[1];
mc[2] = inMC[2];
mc[3] = inMC[3];
}
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
/* Flip face normal */
SWAP(int, mf2->v1, mf2->v3);
if (tf) {
SWAP(unsigned int, tf->col[0], tf->col[2]);
SWAP(float, tf->uv[0][0], tf->uv[2][0]);
SWAP(float, tf->uv[0][1], tf->uv[2][1]);
} else if (mc) {
SWAP(MCol, mc[0], mc[2]);
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
}
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
test_index_face(mf2, mc, tf, inMF->v4?4:3);
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
MEM_freeN(indexMap);
return dlm;
- 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 07:37:15 +00: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 03:08:23 +00:00
static void *mirrorModifier_applyModifier__internal(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int useRenderParams, int isFinalCalc)
- 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 07:37:15 +00:00
{
DerivedMesh *dm = derivedData;
MirrorModifierData *mmd = (MirrorModifierData*) md;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
DispListMesh *outDLM, *inDLM;
- 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 07:37:15 +00:00
if (dm) {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
inDLM = dm->convertToDispListMesh(dm, 1);
- 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 07:37:15 +00:00
} else {
Mesh *me = ob->data;
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
inDLM = MEM_callocN(sizeof(*inDLM), "inDLM");
inDLM->dontFreeVerts = inDLM->dontFreeOther = 1;
inDLM->mvert = me->mvert;
inDLM->medge = me->medge;
inDLM->mface = me->mface;
inDLM->tface = me->tface;
inDLM->mcol = me->mcol;
inDLM->totvert = me->totvert;
inDLM->totedge = me->totedge;
inDLM->totface = me->totface;
- 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 07:37:15 +00: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 03:08:23 +00:00
outDLM = mirrorModifier__doMirror(mmd, inDLM, vertexCos, dm?0:1);
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
displistmesh_free(inDLM);
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 03:08:23 +00:00
mesh_calc_normals(outDLM->mvert, outDLM->totvert, outDLM->mface, outDLM->totface, &outDLM->nors);
return derivedmesh_from_displistmesh(outDLM, NULL);
- 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 05:42:03 +00:00
}
static void *mirrorModifier_applyModifier(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int useRenderParams, int isFinalCalc)
{
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
return mirrorModifier_applyModifier__internal(md, ob, derivedData, vertexCos, 0, 1);
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 07:37:15 +00:00
static void *mirrorModifier_applyModifierEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3])
{
if (derivedData) {
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
return mirrorModifier_applyModifier__internal(md, ob, derivedData, vertexCos, 0, 1);
- 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 07:37:15 +00:00
} else {
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
DispListMesh *inDLM, *outDLM;
- 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 07:37:15 +00:00
MirrorModifierData *mmd = (MirrorModifierData*) md;
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
inDLM = displistmesh_from_editmesh((EditMesh*)editData);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
outDLM = mirrorModifier__doMirror(mmd, inDLM, vertexCos, 0);
displistmesh_free(inDLM);
- 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 07:37:15 +00: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 03:08:23 +00:00
mesh_calc_normals(outDLM->mvert, outDLM->totvert, outDLM->mface, outDLM->totface, &outDLM->nors);
- 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 05:42:03 +00: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 03:08:23 +00:00
return derivedmesh_from_displistmesh(outDLM, 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 07:37:15 +00: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 02:44:59 +00:00
/* Decimate */
static void decimateModifier_initData(ModifierData *md)
{
DecimateModifierData *dmd = (DecimateModifierData*) md;
dmd->percent = 1.0;
}
- assorted warning fixes (signedness, float->double) - added decimate,boolean modifier copydata methods
2005-09-24 16:02:56 +00:00
static void decimateModifier_copyData(ModifierData *md, ModifierData *target)
{
DecimateModifierData *dmd = (DecimateModifierData*) md;
DecimateModifierData *tdmd = (DecimateModifierData*) target;
tdmd->percent = dmd->percent;
}
- 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 02:44:59 +00:00
static void *decimateModifier_applyModifier(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int useRenderParams, int isFinalCalc)
{
DecimateModifierData *dmd = (DecimateModifierData*) md;
DerivedMesh *dm = derivedData;
Mesh *me = ob->data;
MVert *mvert;
MFace *mface;
DispListMesh *ndlm=NULL, *dlm=NULL;
LOD_Decimation_Info lod;
int totvert, totface;
int a, numTris;
if (dm) {
- 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 02:30:29 +00:00
dlm = dm->convertToDispListMesh(dm, 1);
- 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 02:44:59 +00:00
mvert = dlm->mvert;
mface = dlm->mface;
totvert = dlm->totvert;
totface = dlm->totface;
} else {
mvert = me->mvert;
mface = me->mface;
totvert = me->totvert;
totface = me->totface;
}
numTris = 0;
for (a=0; a<totface; a++) {
MFace *mf = &mface[a];
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
numTris++;
if (mf->v4) numTris++;
- 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 02:44:59 +00:00
}
if(numTris<3) {
- 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 07:25:43 +00:00
modifier_setError(md, "There must be more than 3 input faces (triangles).");
goto exit;
- 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 02:44:59 +00:00
}
lod.vertex_buffer= MEM_mallocN(3*sizeof(float)*totvert, "vertices");
lod.vertex_normal_buffer= MEM_mallocN(3*sizeof(float)*totvert, "normals");
lod.triangle_index_buffer= MEM_mallocN(3*sizeof(int)*numTris, "trias");
- decimator modifier was giving wrong # of verts when a previous modifier was active
2005-07-26 23:38:26 +00:00
lod.vertex_num= totvert;
- 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 02:44:59 +00:00
lod.face_num= numTris;
for(a=0; a<totvert; a++) {
MVert *mv = &mvert[a];
float *vbCo = &lod.vertex_buffer[a*3];
float *vbNo = &lod.vertex_normal_buffer[a*3];
- removed BLO_findstruct_offset (obsolete) - remove python access to Optimal and Subsurf flags (they don't work this way anymore, I suppose need to replace with python access to modifiers but not going to do right now). - removed interface access to OPTIMAL mode, needs to be rethough... this means at the moment subsurfs outside editmode always draw and render all edges
2005-08-03 19:56:27 +00:00
if (vertexCos) {
- 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 02:44:59 +00:00
VECCOPY(vbCo, vertexCos[a]);
} else {
VECCOPY(vbCo, mv->co);
}
vbNo[0] = mv->no[0]/32767.0f;
vbNo[1] = mv->no[1]/32767.0f;
vbNo[2] = mv->no[2]/32767.0f;
}
numTris = 0;
for(a=0; a<totface; a++) {
MFace *mf = &mface[a];
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
int *tri = &lod.triangle_index_buffer[3*numTris++];
tri[0]= mf->v1;
tri[1]= mf->v2;
tri[2]= mf->v3;
- 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 02:44:59 +00:00
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
if(mf->v4) {
tri = &lod.triangle_index_buffer[3*numTris++];
- 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 02:44:59 +00:00
tri[0]= mf->v1;
- added mesh_strip_loose_faces, works in conjunction with make_edges to get rid of faces with MFace.v3==0 - change all Mesh's to have ->medge now. This is forced by make_edges on readfile, and in the various exotic important routines, and on conversion back in python. - make python NMesh structure always have medges now (needs testing) - with above two changes it is guarenteed that mf->v3 is never ==0 in main blender code (i.e., all MFace's are actually triangles or quads) and so I went through and removed all the historic tests to deal with MFace.v3==0. Equals lots of deleting, I am in heaven! - removed MEdge edcode flag, no longer needed - added experimental replacement for edge flag system Still are some inconsistencies in FACESELECT mode edge drawing to be ironed out. NOTE: This commit adds an experimental edge flag calc system, based on 10-seconds-of-thought algorithm by yours truly. Would appreciate feedback on how this system works, esp compared to old one and esp on complex or interesting models. To Use: New system is enabled by setting G.rt to a value between 1 and 1000 (Value of 0 uses old system). Value 1000 is reserved for "auto" edge, which is more or less identical to old system but also makes sure that at least 10% of edges are drawn (solves errors for super subdivided meshes). Values between 1 and 999 act as percent (out of 1000) of edges that should be drawn, starting with "most interesting" edges first. Please try it and comment!
2005-08-21 07:19:20 +00:00
tri[1]= mf->v3;
tri[2]= mf->v4;
- 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 02:44:59 +00:00
}
}
dmd->faceCount = 0;
if(LOD_LoadMesh(&lod) ) {
if( LOD_PreprocessMesh(&lod) ) {
/* we assume the decim_faces tells how much to reduce */
while(lod.face_num > numTris*dmd->percent) {
if( LOD_CollapseEdge(&lod)==0) break;
}
ndlm= MEM_callocN(sizeof(DispListMesh), "dispmesh");
ndlm->mvert= MEM_callocN(lod.vertex_num*sizeof(MVert), "mvert");
ndlm->totvert= lod.vertex_num;
Bugfix #3346 Decimate modifier wasn't resistant to decimating below 3 vertices. It now detects so, and doesn't add a face or edges then.
2005-11-21 16:21:03 +00:00
if(lod.vertex_num>2) {
ndlm->mface= MEM_callocN(lod.face_num*sizeof(MFace), "mface");
ndlm->totface= dmd->faceCount = lod.face_num;
}
- 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 02:44:59 +00:00
for(a=0; a<lod.vertex_num; a++) {
MVert *mv = &ndlm->mvert[a];
float *vbCo = &lod.vertex_buffer[a*3];
VECCOPY(mv->co, vbCo);
}
Bugfix #3346 Decimate modifier wasn't resistant to decimating below 3 vertices. It now detects so, and doesn't add a face or edges then.
2005-11-21 16:21:03 +00:00
if(lod.vertex_num>2) {
for(a=0; a<lod.face_num; a++) {
MFace *mf = &ndlm->mface[a];
int *tri = &lod.triangle_index_buffer[a*3];
mf->v1 = tri[0];
mf->v2 = tri[1];
mf->v3 = tri[2];
-- Bugfix 3543: call to test_index_face() in decimateModifier_applyModifier() was passing pointer to the wrong face, which led to eekadoodle later in EditMode.
2005-12-06 00:02:55 +00:00
test_index_face(mf, NULL, NULL, 3);
Bugfix #3346 Decimate modifier wasn't resistant to decimating below 3 vertices. It now detects so, and doesn't add a face or edges then.
2005-11-21 16:21:03 +00:00
}
displistmesh_add_edges(ndlm);
- added iterator to edgehash - updated decimator to make edges
2005-08-23 02:29:22 +00: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 02:44:59 +00:00
}
else {
- 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 07:25:43 +00:00
modifier_setError(md, "Out of memory.");
- 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 02:44:59 +00:00
}
LOD_FreeDecimationData(&lod);
}
else {
- 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 07:25:43 +00:00
modifier_setError(md, "Non-manifold mesh as input.");
- 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 02:44:59 +00:00
}
MEM_freeN(lod.vertex_buffer);
MEM_freeN(lod.vertex_normal_buffer);
MEM_freeN(lod.triangle_index_buffer);
- 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 07:25:43 +00:00
exit:
- 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 02:44:59 +00:00
if (dlm) displistmesh_free(dlm);
if (ndlm) {
mesh_calc_normals(ndlm->mvert, ndlm->totvert, ndlm->mface, ndlm->totface, &ndlm->nors);
- convert all DerivedMesh map functions to use index based mapping (instead of Edit{Vert,Edge,Face} pointers) - dropped convertToDispListMeshMapped (whew, glad of it too) - added DerivedMesh drawMappedFaces function - dropped EM suffix for DerivedMesh functions, it was neither particularly correct nor descriptive - converted test_index_mface to test_index_face that also corrects MCol and TFace. Good thing we had three versions of this routine, you never know when one might burn down. - removed flipnorm_mesh, not used anymore (and was incorrect to boot) - Getting face select to work with modifiers turned out to be much more complicated than expected. Reworked mapping architecture for modifiers - basically elements in a DispListMesh are now required to be stored in an order that corresponds exactly to original ordering. MVert/MEdge/MFace all have a new flag ME_XXX_STEPINDEX that is set on each element that is set on the first derived element of each original element. I can't say the code to follow these requirements for subsurf is particularly transparent, but on the upside it is a reasonably consistent and simple system that is memory efficient and allows keeping the DispListMesh structure. - rewrote mirror modifier to be simpler/conform to new requirements for mapped DispListMesh structure. This also means that mirror interacts much better with incremental subsurf calculation (it used to recalc one entire side on any topology change, now it generally avoids that). - added EM_{init,free}_index_arrays and EM_get_{vert,edge,face}_for_index functions to handle mapping indices back into appropriate EditMesh structures. - bug fix, make edges didn't recalc object data - bug fix, initial image assignment to TFace's didn't recalc object data - new feature, added circle select support for FACESELECT - bug fix, creating new faces in editmode duplicated the TFACE active flag - but there should only be one active tface - bug fix, possible crash when deleting all faces in faceselect mode on mesh with tfaces... Still todo: TFace edge drawing is still not always correct in face mode, in particular with a mirror modifier when mesh has edges (and no preceeding subsurf). Have not yet decided how to deal with this. Best solution is probably to do switch to meshes all having MEdge's, in which case I can get rid of TFace edge flags (and need to recalc modifiers on tface selection change).
2005-08-20 03:08:23 +00:00
return derivedmesh_from_displistmesh(ndlm, NULL);
- 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 02:44:59 +00:00
} else {
return NULL;
}
}
/* Wave */
static void waveModifier_initData(ModifierData *md)
{
WaveModifierData *wmd = (WaveModifierData*) md; // whadya know, moved here from Iraq
wmd->flag |= (WAV_X+WAV_Y+WAV_CYCL);
wmd->height= 0.5f;
wmd->width= 1.5f;
wmd->speed= 0.5f;
wmd->narrow= 1.5f;
wmd->lifetime= 0.0f;
wmd->damp= 10.0f;
}
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
static void waveModifier_copyData(ModifierData *md, ModifierData *target)
{
WaveModifierData *wmd = (WaveModifierData*) md;
WaveModifierData *twmd = (WaveModifierData*) target;
twmd->damp = wmd->damp;
twmd->flag = wmd->flag;
twmd->height = wmd->height;
twmd->lifetime = wmd->lifetime;
twmd->narrow = wmd->narrow;
twmd->speed = wmd->speed;
twmd->startx = wmd->startx;
twmd->starty = wmd->starty;
twmd->timeoffs = wmd->timeoffs;
twmd->width = wmd->width;
}
- 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 02:44:59 +00:00
static int waveModifier_dependsOnTime(ModifierData *md)
{
return 1;
}
static void waveModifier_deformVerts(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int numVerts)
{
WaveModifierData *wmd = (WaveModifierData*) md;
float ctime = bsystem_time(ob, 0, (float)G.scene->r.cfra, 0.0);
float minfac = (float)(1.0/exp(wmd->width*wmd->narrow*wmd->width*wmd->narrow));
float lifefac = wmd->height;
if(wmd->damp==0) wmd->damp= 10.0f;
if(wmd->lifetime!=0.0) {
float x= ctime - wmd->timeoffs;
if(x>wmd->lifetime) {
lifefac= x-wmd->lifetime;
if(lifefac > wmd->damp) lifefac= 0.0;
else lifefac= (float)(wmd->height*(1.0 - sqrt(lifefac/wmd->damp)));
}
}
if(lifefac!=0.0) {
int i;
for (i=0; i<numVerts; i++) {
float *co = vertexCos[i];
float x= co[0]-wmd->startx;
float y= co[1]-wmd->starty;
Bugfix #4563 Wave Modifier defaulted to Y waves, even when both X and Y buttons were disabled. That case isn't very useful, nevertheless... if buttons allows it then it should just work!
2006-07-02 10:36:26 +00:00
float amplit= 0.0f;
- 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 02:44:59 +00:00
if(wmd->flag & WAV_X) {
if(wmd->flag & WAV_Y) amplit= (float)sqrt( (x*x + y*y));
else amplit= x;
}
Bugfix #4563 Wave Modifier defaulted to Y waves, even when both X and Y buttons were disabled. That case isn't very useful, nevertheless... if buttons allows it then it should just work!
2006-07-02 10:36:26 +00:00
else if(wmd->flag & WAV_Y)
amplit= y;
- 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 02:44:59 +00:00
/* this way it makes nice circles */
amplit-= (ctime-wmd->timeoffs)*wmd->speed;
if(wmd->flag & WAV_CYCL) {
amplit = (float)fmod(amplit-wmd->width, 2.0*wmd->width) + wmd->width;
}
/* GAUSSIAN */
if(amplit> -wmd->width && amplit<wmd->width) {
amplit = amplit*wmd->narrow;
amplit= (float)(1.0/exp(amplit*amplit) - minfac);
co[2]+= lifefac*amplit;
}
}
}
}
static void waveModifier_deformVertsEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3], int numVerts)
{
waveModifier_deformVerts(md, ob, NULL, vertexCos, numVerts);
}
- 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-10 22:05:52 +00:00
/* Armature */
Modifier fix; new Armature modifier added sets the deform flags on. (Note; until 2.40 release, these flags are also still in the Armature Panel, that will disappear then)
2005-11-05 21:51:12 +00:00
static void armatureModifier_initData(ModifierData *md)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
amd->deformflag = ARM_DEF_ENVELOPE|ARM_DEF_VGROUP;
}
- 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-10 22:05:52 +00:00
static void armatureModifier_copyData(ModifierData *md, ModifierData *target)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
ArmatureModifierData *tamd = (ArmatureModifierData*) target;
tamd->object = amd->object;
Another option for more Armature deform control; The "Use VGroup" or "Use Envelope" options now are in Modifier Panel for Armature deform. If Modifiers are in use, they override the Armature settings for it. (Cannot get rid of the Armature panel options yet, since Blender still allows parenting to be deforming too, which is displayed as a Virtual modifier now) This now allows to - for example - make a Envelope deform on a Lattice, and have same Armature use vertexgroups on Mesh. Next; vertexgroup option for Lattice & Curve deform
2005-10-20 16:31:46 +00:00
tamd->deformflag = amd->deformflag;
- 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-10 22:05:52 +00:00
}
static int armatureModifier_isDisabled(ModifierData *md)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
return !amd->object;
}
static void armatureModifier_foreachObjectLink(ModifierData *md, Object *ob, void (*walk)(void *userData, Object *ob, Object **obpoin), void *userData)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
walk(userData, ob, &amd->object);
}
static void armatureModifier_updateDepgraph(ModifierData *md, DagForest *forest, Object *ob, DagNode *obNode)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
if (amd->object) {
DagNode *curNode = dag_get_node(forest, amd->object);
dag_add_relation(forest, curNode, obNode, DAG_RL_DATA_DATA|DAG_RL_OB_DATA);
}
}
static void armatureModifier_deformVerts(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int numVerts)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
Another option for more Armature deform control; The "Use VGroup" or "Use Envelope" options now are in Modifier Panel for Armature deform. If Modifiers are in use, they override the Armature settings for it. (Cannot get rid of the Armature panel options yet, since Blender still allows parenting to be deforming too, which is displayed as a Virtual modifier now) This now allows to - for example - make a Envelope deform on a Lattice, and have same Armature use vertexgroups on Mesh. Next; vertexgroup option for Lattice & Curve deform
2005-10-20 16:31:46 +00:00
armature_deform_verts(amd->object, ob, vertexCos, numVerts, amd->deformflag);
- 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-10 22:05:52 +00:00
}
static void armatureModifier_deformVertsEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3], int numVerts)
{
ArmatureModifierData *amd = (ArmatureModifierData*) md;
Another option for more Armature deform control; The "Use VGroup" or "Use Envelope" options now are in Modifier Panel for Armature deform. If Modifiers are in use, they override the Armature settings for it. (Cannot get rid of the Armature panel options yet, since Blender still allows parenting to be deforming too, which is displayed as a Virtual modifier now) This now allows to - for example - make a Envelope deform on a Lattice, and have same Armature use vertexgroups on Mesh. Next; vertexgroup option for Lattice & Curve deform
2005-10-20 16:31:46 +00:00
armature_deform_verts(amd->object, ob, vertexCos, numVerts, amd->deformflag);
- 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-10 22:05:52 +00:00
}
/* Hook */
static void hookModifier_initData(ModifierData *md)
{
HookModifierData *hmd = (HookModifierData*) md;
hmd->force= 1.0;
}
static void hookModifier_copyData(ModifierData *md, ModifierData *target)
{
HookModifierData *hmd = (HookModifierData*) md;
HookModifierData *thmd = (HookModifierData*) target;
VECCOPY(thmd->cent, hmd->cent);
thmd->falloff = hmd->falloff;
thmd->force = hmd->force;
thmd->object = hmd->object;
thmd->totindex = hmd->totindex;
thmd->indexar = MEM_dupallocN(hmd->indexar);
memcpy(thmd->parentinv, hmd->parentinv, sizeof(hmd->parentinv));
}
static void hookModifier_freeData(ModifierData *md)
{
HookModifierData *hmd = (HookModifierData*) md;
if (hmd->indexar) MEM_freeN(hmd->indexar);
}
static int hookModifier_isDisabled(ModifierData *md)
{
HookModifierData *hmd = (HookModifierData*) md;
return !hmd->object;
}
static void hookModifier_foreachObjectLink(ModifierData *md, Object *ob, void (*walk)(void *userData, Object *ob, Object **obpoin), void *userData)
{
HookModifierData *hmd = (HookModifierData*) md;
walk(userData, ob, &hmd->object);
}
static void hookModifier_updateDepgraph(ModifierData *md, DagForest *forest, Object *ob, DagNode *obNode)
{
HookModifierData *hmd = (HookModifierData*) md;
if (hmd->object) {
DagNode *curNode = dag_get_node(forest, hmd->object);
dag_add_relation(forest, curNode, obNode, DAG_RL_OB_DATA);
}
}
static void hookModifier_deformVerts(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int numVerts)
{
HookModifierData *hmd = (HookModifierData*) md;
float vec[3], mat[4][4];
int i;
Mat4Invert(ob->imat, ob->obmat);
Mat4MulSerie(mat, ob->imat, hmd->object->obmat, hmd->parentinv, NULL, NULL, NULL, NULL, NULL);
New! Hooks now support vertex groups. With weight painting it looks very interesting. Almost z-painting! :) Try a sphere with all vertices in a group, hook it, and scale empty in object mode a bit. http://www.blender.org/bf/rt3.jpg (Which gives the idea to make a Displace Modifier working with normals and vertexgroups..) Works as follows now; in Mesh editmode, when no vertices are selected, it tries to assign on CTRL+H command the active Vertex Group. (Menu is getting to long now... need to think over). Only works when vertices are assigned to a Vertex Group, this to calculate the Hook center.
2005-09-24 20:17:48 +00:00
/* vertex indices? */
if(hmd->indexar) {
for (i=0; i<hmd->totindex; i++) {
int index = hmd->indexar[i];
/* This should always be true and I don't generally like
* "paranoid" style code like this, but old files can have
* indices that are out of range because old blender did
* not correct them on exit editmode. - zr
*/
if (index<numVerts) {
float *co = vertexCos[index];
float fac = hmd->force;
if(hmd->falloff!=0.0) {
float len= VecLenf(co, hmd->cent);
if(len > hmd->falloff) fac = 0.0;
else if(len>0.0) fac *= sqrt(1.0 - len/hmd->falloff);
}
- 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-10 22:05:52 +00:00
New! Hooks now support vertex groups. With weight painting it looks very interesting. Almost z-painting! :) Try a sphere with all vertices in a group, hook it, and scale empty in object mode a bit. http://www.blender.org/bf/rt3.jpg (Which gives the idea to make a Displace Modifier working with normals and vertexgroups..) Works as follows now; in Mesh editmode, when no vertices are selected, it tries to assign on CTRL+H command the active Vertex Group. (Menu is getting to long now... need to think over). Only works when vertices are assigned to a Vertex Group, this to calculate the Hook center.
2005-09-24 20:17:48 +00:00
if(fac!=0.0) {
VecMat4MulVecfl(vec, mat, co);
VecLerpf(co, co, vec, fac);
}
}
}
}
else { /* vertex group hook */
bDeformGroup *curdef;
Mesh *me= ob->data;
int index=0;
/* find the group (weak loop-in-loop) */
for (curdef = ob->defbase.first; curdef; curdef=curdef->next, index++)
if (!strcmp(curdef->name, hmd->name))
break;
if(curdef && me->dvert) {
MDeformVert *dvert= me->dvert;
int i, j;
for (i=0; i < me->totvert; i++, dvert++) {
for(j=0; j<dvert->totweight; j++) {
if (dvert->dw[j].def_nr == index) {
float fac = hmd->force*dvert->dw[j].weight;
float *co = vertexCos[i];
if(hmd->falloff!=0.0) {
float len= VecLenf(co, hmd->cent);
if(len > hmd->falloff) fac = 0.0;
else if(len>0.0) fac *= sqrt(1.0 - len/hmd->falloff);
}
VecMat4MulVecfl(vec, mat, co);
VecLerpf(co, co, vec, fac);
}
}
- bug fix, hook deform could crash because old files can have hook indices that are out of range - bug fix, hook indicies were not corrected on exit editmode (there probably should be a general interface for this kind of patch)
2005-08-10 22:25:32 +00: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-10 22:05:52 +00:00
}
New! Hooks now support vertex groups. With weight painting it looks very interesting. Almost z-painting! :) Try a sphere with all vertices in a group, hook it, and scale empty in object mode a bit. http://www.blender.org/bf/rt3.jpg (Which gives the idea to make a Displace Modifier working with normals and vertexgroups..) Works as follows now; in Mesh editmode, when no vertices are selected, it tries to assign on CTRL+H command the active Vertex Group. (Menu is getting to long now... need to think over). Only works when vertices are assigned to a Vertex Group, this to calculate the Hook center.
2005-09-24 20:17:48 +00: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-10 22:05:52 +00:00
}
}
static void hookModifier_deformVertsEM(ModifierData *md, Object *ob, void *editData, void *derivedData, float (*vertexCos)[3], int numVerts)
{
hookModifier_deformVerts(md, ob, derivedData, vertexCos, numVerts);
}
/* Softbody */
static void softbodyModifier_deformVerts(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int numVerts)
{
- readded DL_VERTS type to store lattice deformed verts - new feature, twiddled with lattice resizing to try to maintain existing vertex changes... much nicer than just resetting the lattice if you decide you need more detail in the lattice. - modifiers work with lattices now. yes, that does mean you can make a chain of lattices effecting each other 8 miles long. - some cleanup of softbody code, was rather splintered and call path was twisted and confusing. reworked main object step routine to do things in a more obvious and consistent manner and without duplicate code - added ob->softflag OB_SB_RESET instead of sbObjectReset call - modifier changes reset softbody now - moved curve_getVertexCos/curve_applyVertexCos into curve.c - update curve modifier eval to work with virtual modifiers - update modifier apply to work with curves/surfs - update make parent to also recalc object data NOTE: Although you can turn SB on for curve/font objects at the moment it doesn't really work because they call deform in multiple steps and this confuses SB. Not sure how to deal with atm.
2005-08-15 10:30:53 +00:00
sbObjectStep(ob, (float)G.scene->r.cfra, vertexCos, numVerts);
- 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-10 22:05:52 +00: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 02:44:59 +00:00
Saturday morning first cup of coffee hack (yeah, its a late morning) - fun for the whole family, boolean mesh modifier... doesn't work with layered modifiers yet (just uses base mesh), although may god have mercy on your soul if you want to run boolean on a subsurf anyway - added displistmesh_add_edges This exposes a bug in boolean, apparently the output is somehow random (hash on alloc'd pointer value perhaps) which is sortof lame. It also makes more apparent the desire for some level of control over dep graph evaluation during editmode (at the moment dep graph is reevaluated for a mesh object in editmode, but since mesh changes are on editmesh other objects don't really see any change, so it is a wasted recalc).
2005-09-03 17:22:29 +00:00
/* Boolean */
- assorted warning fixes (signedness, float->double) - added decimate,boolean modifier copydata methods
2005-09-24 16:02:56 +00:00
static void booleanModifier_copyData(ModifierData *md, ModifierData *target)
{
BooleanModifierData *bmd = (BooleanModifierData*) md;
BooleanModifierData *tbmd = (BooleanModifierData*) target;
tbmd->object = bmd->object;
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 19:19:44 +00:00
tbmd->operation = bmd->operation;
- assorted warning fixes (signedness, float->double) - added decimate,boolean modifier copydata methods
2005-09-24 16:02:56 +00:00
}
Saturday morning first cup of coffee hack (yeah, its a late morning) - fun for the whole family, boolean mesh modifier... doesn't work with layered modifiers yet (just uses base mesh), although may god have mercy on your soul if you want to run boolean on a subsurf anyway - added displistmesh_add_edges This exposes a bug in boolean, apparently the output is somehow random (hash on alloc'd pointer value perhaps) which is sortof lame. It also makes more apparent the desire for some level of control over dep graph evaluation during editmode (at the moment dep graph is reevaluated for a mesh object in editmode, but since mesh changes are on editmesh other objects don't really see any change, so it is a wasted recalc).
2005-09-03 17:22:29 +00:00
static int booleanModifier_isDisabled(ModifierData *md)
{
BooleanModifierData *bmd = (BooleanModifierData*) md;
return !bmd->object;
}
static void booleanModifier_foreachObjectLink(ModifierData *md, Object *ob, void (*walk)(void *userData, Object *ob, Object **obpoin), void *userData)
{
BooleanModifierData *bmd = (BooleanModifierData*) md;
walk(userData, ob, &bmd->object);
}
static void booleanModifier_updateDepgraph(ModifierData *md, DagForest *forest, Object *ob, DagNode *obNode)
{
BooleanModifierData *bmd = (BooleanModifierData*) md;
if (bmd->object) {
DagNode *curNode = dag_get_node(forest, bmd->object);
dag_add_relation(forest, curNode, obNode, DAG_RL_DATA_DATA|DAG_RL_OB_DATA);
}
}
static void *booleanModifier_applyModifier(ModifierData *md, Object *ob, void *derivedData, float (*vertexCos)[3], int useRenderParams, int isFinalCalc)
{
// XXX doesn't handle derived data
BooleanModifierData *bmd = (BooleanModifierData*) md;
Inserted a sanity check in the boolean modifier (not the Wkey, but the modifier buttons). Prevents crashing on input of meshes with less than 4 faces.
2005-12-19 17:21:55 +00:00
/* we do a quick sanity check */
if( ((Mesh *)ob->data)->totface>3 && bmd->object && ((Mesh *)bmd->object->data)->totface>3) {
DispListMesh *dlm= NewBooleanMeshDLM(bmd->object, ob, 1+bmd->operation);
Fix boolean modifier crash; if boolean code cannot do the operation on the meshes, print an error dialog and delete the modifier object.
2006-01-01 15:41:20 +00:00
/* if new mesh returned, get derived mesh; otherwise there was
* an error, so delete the modifier object */
if( dlm )
return derivedmesh_from_displistmesh(dlm, NULL);
else
bmd->object = NULL;
Inserted a sanity check in the boolean modifier (not the Wkey, but the modifier buttons). Prevents crashing on input of meshes with less than 4 faces.
2005-12-19 17:21:55 +00:00
}
Fix boolean modifier crash; if boolean code cannot do the operation on the meshes, print an error dialog and delete the modifier object.
2006-01-01 15:41:20 +00:00
return derivedData;
Saturday morning first cup of coffee hack (yeah, its a late morning) - fun for the whole family, boolean mesh modifier... doesn't work with layered modifiers yet (just uses base mesh), although may god have mercy on your soul if you want to run boolean on a subsurf anyway - added displistmesh_add_edges This exposes a bug in boolean, apparently the output is somehow random (hash on alloc'd pointer value perhaps) which is sortof lame. It also makes more apparent the desire for some level of control over dep graph evaluation during editmode (at the moment dep graph is reevaluated for a mesh object in editmode, but since mesh changes are on editmesh other objects don't really see any change, so it is a wasted recalc).
2005-09-03 17:22:29 +00: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 20:14:17 +00:00
/***/
static ModifierTypeInfo typeArr[NUM_MODIFIER_TYPES];
static int typeArrInit = 1;
- 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 04:04:05 +00:00
ModifierTypeInfo *modifierType_getInfo(ModifierType 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 20:14:17 +00:00
{
if (typeArrInit) {
ModifierTypeInfo *mti;
memset(typeArr, 0, sizeof(typeArr));
- 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 20:30:33 +00:00
/* Initialize and return the appropriate type info structure,
* assumes that modifier has:
* name == typeName,
* structName == typeName + 'ModifierData'
*/
#define INIT_TYPE(typeName) \
( strcpy(typeArr[eModifierType_##typeName].name, #typeName), \
strcpy(typeArr[eModifierType_##typeName].structName, #typeName "ModifierData"), \
typeArr[eModifierType_##typeName].structSize = sizeof(typeName##ModifierData), \
&typeArr[eModifierType_##typeName])
- 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 20:14:17 +00:00
mti = &typeArr[eModifierType_None];
strcpy(mti->name, "None");
strcpy(mti->structName, "ModifierData");
- 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 20:30:33 +00:00
mti->structSize = sizeof(ModifierData);
- 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 20:14:17 +00:00
mti->type = eModifierType_None;
mti->flags = eModifierTypeFlag_AcceptsMesh|eModifierTypeFlag_AcceptsCVs;
mti->isDisabled = noneModifier_isDisabled;
- 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 20:30:33 +00:00
mti = INIT_TYPE(Curve);
- 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 20:14:17 +00:00
mti->type = eModifierTypeType_OnlyDeform;
Curve and Lattice deform Modifiers now accept optional Vertex Group name to finetune deform further as well. Note that curve deform requires object buttons 'track' and 'up' axes set properly. Curve deform can twist/flip a lot, making Vertex Group based deform hard to set up.
2005-10-20 18:52:29 +00:00
mti->flags = eModifierTypeFlag_AcceptsCVs | eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_RequiresOriginalData;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
mti->copyData = curveModifier_copyData;
- 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 20:14:17 +00:00
mti->isDisabled = curveModifier_isDisabled;
- 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-10 22:05:52 +00:00
mti->foreachObjectLink = curveModifier_foreachObjectLink;
- added ModifierTypeInfo.updateDepgraph function, responsible for building appropriate relations in dep graph (modifiers respond to scene changes correctly now) - update modifier buttons to trigger depgraph rebuild if needed
2005-07-19 23:04:34 +00:00
mti->updateDepgraph = curveModifier_updateDepgraph;
- 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 20:14:17 +00:00
mti->deformVerts = curveModifier_deformVerts;
- 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 07:37:15 +00:00
mti->deformVertsEM = curveModifier_deformVertsEM;
- 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 20:14:17 +00: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 20:30:33 +00:00
mti = INIT_TYPE(Lattice);
- 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 20:14:17 +00:00
mti->type = eModifierTypeType_OnlyDeform;
Curve and Lattice deform Modifiers now accept optional Vertex Group name to finetune deform further as well. Note that curve deform requires object buttons 'track' and 'up' axes set properly. Curve deform can twist/flip a lot, making Vertex Group based deform hard to set up.
2005-10-20 18:52:29 +00:00
mti->flags = eModifierTypeFlag_AcceptsCVs | eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_RequiresOriginalData;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
mti->copyData = latticeModifier_copyData;
- 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 20:14:17 +00:00
mti->isDisabled = latticeModifier_isDisabled;
- 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-10 22:05:52 +00:00
mti->foreachObjectLink = latticeModifier_foreachObjectLink;
- added ModifierTypeInfo.updateDepgraph function, responsible for building appropriate relations in dep graph (modifiers respond to scene changes correctly now) - update modifier buttons to trigger depgraph rebuild if needed
2005-07-19 23:04:34 +00:00
mti->updateDepgraph = latticeModifier_updateDepgraph;
- 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 20:14:17 +00:00
mti->deformVerts = latticeModifier_deformVerts;
- 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 07:37:15 +00:00
mti->deformVertsEM = latticeModifier_deformVertsEM;
- 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 20:14:17 +00: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 20:30:33 +00:00
mti = INIT_TYPE(Subsurf);
- 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 20:14:17 +00:00
mti->type = eModifierTypeType_Constructive;
- 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 19:15:08 +00:00
mti->flags = eModifierTypeFlag_AcceptsMesh | eModifierTypeFlag_SupportsMapping | eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_EnableInEditmode;
- 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 20:30:33 +00:00
mti->initData = subsurfModifier_initData;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
mti->copyData = subsurfModifier_copyData;
- 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 20:30:33 +00:00
mti->freeData = subsurfModifier_freeData;
- 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 20:14:17 +00:00
mti->applyModifier = subsurfModifier_applyModifier;
- 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 07:37:15 +00:00
mti->applyModifierEM = subsurfModifier_applyModifierEM;
- 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 20:14:17 +00: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 20:30:33 +00:00
mti = INIT_TYPE(Build);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
mti->type = eModifierTypeType_Nonconstructive;
mti->flags = eModifierTypeFlag_AcceptsMesh;
- 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 20:30:33 +00:00
mti->initData = buildModifier_initData;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
mti->copyData = buildModifier_copyData;
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
mti->dependsOnTime = buildModifier_dependsOnTime;
mti->applyModifier = buildModifier_applyModifier;
Array modifier patch by Ben Batt! (#3788) This modifier allows to make arrays of meshes, with multiple offset types: - constant offset - offset relative to object width - offset with scale and rotation based on another object The number of duplicates can be computed based on a fixed count, fixed length or length of a curve. Duplicate vertices can be automatically merged. Nice docs and example files available in the wiki: http://mediawiki.blender.org/index.php/BlenderDev/ArrayModifier
2006-03-01 15:30:10 +00:00
mti = INIT_TYPE(Array);
mti->type = eModifierTypeType_Constructive;
mti->flags = eModifierTypeFlag_AcceptsMesh
| eModifierTypeFlag_SupportsMapping
| eModifierTypeFlag_SupportsEditmode
| eModifierTypeFlag_EnableInEditmode;
mti->initData = arrayModifier_initData;
mti->copyData = arrayModifier_copyData;
mti->foreachObjectLink = arrayModifier_foreachObjectLink;
mti->updateDepgraph = arrayModifier_updateDepgraph;
mti->applyModifier = arrayModifier_applyModifier;
mti->applyModifierEM = arrayModifier_applyModifierEM;
- 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 20:30:33 +00:00
mti = INIT_TYPE(Mirror);
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
mti->type = eModifierTypeType_Constructive;
- 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 05:42:03 +00:00
mti->flags = eModifierTypeFlag_AcceptsMesh | eModifierTypeFlag_SupportsMapping | eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_EnableInEditmode;
- 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 20:30:33 +00:00
mti->initData = mirrorModifier_initData;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
mti->copyData = mirrorModifier_copyData;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00:00
mti->applyModifier = mirrorModifier_applyModifier;
- 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 07:37:15 +00:00
mti->applyModifierEM = mirrorModifier_applyModifierEM;
Wow! A new feature! - made ModifierData.isDisabled optional - Added new modifier type: Mirror o modifier system isn't running in editmode yet so still don't have mirrored editing, but otherwise it is pretty cool. code even goes to tricks to make sure mirror join looks nice in degenerate cases. o this kind of commit is basically the upshot of all the previous commits - in that implementing a new modifier changes only about 3 files and still integrates nearly completely.
2005-07-20 07:11:26 +00: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 02:44:59 +00:00
mti = INIT_TYPE(Decimate);
mti->type = eModifierTypeType_Nonconstructive;
mti->flags = eModifierTypeFlag_AcceptsMesh;
mti->initData = decimateModifier_initData;
- assorted warning fixes (signedness, float->double) - added decimate,boolean modifier copydata methods
2005-09-24 16:02:56 +00:00
mti->copyData = decimateModifier_copyData;
- 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 02:44:59 +00:00
mti->applyModifier = decimateModifier_applyModifier;
mti = INIT_TYPE(Wave);
mti->type = eModifierTypeType_OnlyDeform;
mti->flags = eModifierTypeFlag_AcceptsCVs | eModifierTypeFlag_SupportsEditmode;
mti->initData = waveModifier_initData;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
mti->copyData = waveModifier_copyData;
- 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 02:44:59 +00:00
mti->dependsOnTime = waveModifier_dependsOnTime;
mti->deformVerts = waveModifier_deformVerts;
mti->deformVertsEM = waveModifier_deformVertsEM;
- 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-10 22:05:52 +00:00
mti = INIT_TYPE(Armature);
mti->type = eModifierTypeType_OnlyDeform;
Two quick bugfixes, thanks slikdigit! - armature modifier was not flagged to require original data (but it does) - add hook messed up the ModifierData initialization, stupid bug!
2005-08-11 05:45:47 +00:00
mti->flags = eModifierTypeFlag_AcceptsCVs | eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_RequiresOriginalData;
Modifier fix; new Armature modifier added sets the deform flags on. (Note; until 2.40 release, these flags are also still in the Armature Panel, that will disappear then)
2005-11-05 21:51:12 +00:00
mti->initData = armatureModifier_initData;
- 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-10 22:05:52 +00:00
mti->copyData = armatureModifier_copyData;
mti->isDisabled = armatureModifier_isDisabled;
mti->foreachObjectLink = armatureModifier_foreachObjectLink;
mti->updateDepgraph = armatureModifier_updateDepgraph;
mti->deformVerts = armatureModifier_deformVerts;
mti->deformVertsEM = armatureModifier_deformVertsEM;
mti = INIT_TYPE(Hook);
mti->type = eModifierTypeType_OnlyDeform;
mti->flags = eModifierTypeFlag_AcceptsCVs | eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_RequiresOriginalData;
mti->initData = hookModifier_initData;
mti->copyData = hookModifier_copyData;
mti->freeData = hookModifier_freeData;
mti->isDisabled = hookModifier_isDisabled;
mti->foreachObjectLink = hookModifier_foreachObjectLink;
mti->updateDepgraph = hookModifier_updateDepgraph;
mti->deformVerts = hookModifier_deformVerts;
mti->deformVertsEM = hookModifier_deformVertsEM;
mti = INIT_TYPE(Softbody);
mti->type = eModifierTypeType_OnlyDeform;
- switch to using softbody modifier, controls enabling but does not have variables, these are still in same place. enable button automatically makes/enables modifier. - changed hook to hook modifier conversion to happen on direct link, required to make sure we don't forget to free any memory for files saved with 2.38 that have hooks. - update modifier interface to enforce modifiers with the require-original- data flag to not move beyond deforming modifiers. - enforce only one softbody modifier allowed NOTE: Once again, no modifier stack for lattice yet means softbody for lattice does not work atm.
2005-08-11 02:23:52 +00:00
mti->flags = eModifierTypeFlag_AcceptsCVs | eModifierTypeFlag_RequiresOriginalData;
- 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-10 22:05:52 +00:00
mti->deformVerts = softbodyModifier_deformVerts;
Saturday morning first cup of coffee hack (yeah, its a late morning) - fun for the whole family, boolean mesh modifier... doesn't work with layered modifiers yet (just uses base mesh), although may god have mercy on your soul if you want to run boolean on a subsurf anyway - added displistmesh_add_edges This exposes a bug in boolean, apparently the output is somehow random (hash on alloc'd pointer value perhaps) which is sortof lame. It also makes more apparent the desire for some level of control over dep graph evaluation during editmode (at the moment dep graph is reevaluated for a mesh object in editmode, but since mesh changes are on editmesh other objects don't really see any change, so it is a wasted recalc).
2005-09-03 17:22:29 +00:00
mti = INIT_TYPE(Boolean);
mti->type = eModifierTypeType_Nonconstructive;
Bugfix #4520 Boolean modifier allowed to be added after subsurf, but it doesn't support that. Added "eModifierTypeFlag_RequiresOriginalData" flag to prevent this from happening in UI.
2006-06-28 14:02:11 +00:00
mti->flags = eModifierTypeFlag_AcceptsMesh | eModifierTypeFlag_RequiresOriginalData;
- assorted warning fixes (signedness, float->double) - added decimate,boolean modifier copydata methods
2005-09-24 16:02:56 +00:00
mti->copyData = booleanModifier_copyData;
Saturday morning first cup of coffee hack (yeah, its a late morning) - fun for the whole family, boolean mesh modifier... doesn't work with layered modifiers yet (just uses base mesh), although may god have mercy on your soul if you want to run boolean on a subsurf anyway - added displistmesh_add_edges This exposes a bug in boolean, apparently the output is somehow random (hash on alloc'd pointer value perhaps) which is sortof lame. It also makes more apparent the desire for some level of control over dep graph evaluation during editmode (at the moment dep graph is reevaluated for a mesh object in editmode, but since mesh changes are on editmesh other objects don't really see any change, so it is a wasted recalc).
2005-09-03 17:22:29 +00:00
mti->isDisabled = booleanModifier_isDisabled;
mti->applyModifier = booleanModifier_applyModifier;
mti->foreachObjectLink = booleanModifier_foreachObjectLink;
mti->updateDepgraph = booleanModifier_updateDepgraph;
- 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 20:14:17 +00:00
typeArrInit = 0;
- 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 20:30:33 +00:00
#undef INIT_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 20:14:17 +00:00
}
if (type>=0 && type<NUM_MODIFIER_TYPES && typeArr[type].name[0]!='\0') {
return &typeArr[type];
} else {
return NULL;
}
}
- 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-10 22:05:52 +00: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 20:30:33 +00:00
ModifierData *modifier_new(int type)
{
- 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 04:04:05 +00:00
ModifierTypeInfo *mti = modifierType_getInfo(type);
- 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 20:30:33 +00:00
ModifierData *md = MEM_callocN(mti->structSize, mti->structName);
- 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-10 22:05:52 +00:00
strcpy(md->name, mti->name);
- 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 20:30:33 +00:00
md->type = type;
- 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 07:25:43 +00:00
md->mode = eModifierMode_Realtime|eModifierMode_Render|eModifierMode_Expanded;
- 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 19:15:08 +00:00
if (mti->flags&eModifierTypeFlag_EnableInEditmode)
md->mode |= eModifierMode_Editmode;
- 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 20:30:33 +00:00
if (mti->initData) mti->initData(md);
return md;
}
void modifier_free(ModifierData *md)
{
- 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 04:04:05 +00:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- 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 20:30:33 +00:00
if (mti->freeData) mti->freeData(md);
- 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 07:25:43 +00:00
if (md->error) MEM_freeN(md->error);
- 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 20:30:33 +00:00
MEM_freeN(md);
}
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
int modifier_dependsOnTime(ModifierData *md)
{
- 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 04:04:05 +00:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- added modifier_dependsOnTime to check if modifier needs updating based on time change. would be nice if dep graph could handle this. - made dep check if modifiers need update on time change - fix render crash (access null) - added new Build Effect modifier type. compared to old one works as a full member of modifier system, means can apply subsurf, etc on it, reorder, what have you. and it is all nice and self contained. - removed old Build effect, old files convert to new style on load - couldn't help myself, added a randomize feature to build effect - removed Python BuildEffect support
2005-07-20 04:14:21 +00:00
return mti->dependsOnTime && mti->dependsOnTime(md);
}
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00: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 04:04:05 +00:00
int modifier_supportsMapping(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
return ( (mti->flags&eModifierTypeFlag_SupportsEditmode) &&
( (mti->type==eModifierTypeType_OnlyDeform ||
(mti->flags&eModifierTypeFlag_SupportsMapping))) );
}
- 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-10 22:05:52 +00:00
ModifierData *modifiers_findByType(Object *ob, ModifierType type)
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00: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-10 22:05:52 +00:00
ModifierData *md = ob->modifiers.first;
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
for (; md; md=md->next)
if (md->type==type)
break;
return md;
}
- 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-10 22:05:52 +00:00
void modifiers_clearErrors(Object *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 07:25:43 +00: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-10 22:05:52 +00:00
ModifierData *md = ob->modifiers.first;
int qRedraw = 0;
- 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 07:25:43 +00:00
for (; md; md=md->next) {
if (md->error) {
MEM_freeN(md->error);
md->error = NULL;
- 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-10 22:05:52 +00:00
qRedraw = 1;
- 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 07:25:43 +00: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-10 22:05:52 +00:00
if (qRedraw) allqueue(REDRAWBUTSEDIT, 0);
}
void modifiers_foreachObjectLink(Object *ob, void (*walk)(void *userData, Object *ob, Object **obpoin), void *userData)
{
ModifierData *md = ob->modifiers.first;
for (; md; md=md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if (mti->foreachObjectLink) mti->foreachObjectLink(md, ob, walk, userData);
}
- 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 07:25:43 +00:00
}
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
void modifier_copyData(ModifierData *md, ModifierData *target)
{
- 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 04:04:05 +00:00
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
- update storage.c to use standard time codes (should fix issue with MSVS 8) - broke mesh_create_shadedColors out of shadeDispList, used to build vertex colors for mesh in vpaint as well (also fixed bug where they were not initialized correctly for subsurfs) - added modifier_copyData and modifier_findByType functions - change editmode modifiers to only calculate if Realtime and Editmode bits are both set, makes more sense for copying modifiers - update object_copy to correctly copy modifiers - removed duplicate redefinition of ME_ attributes in python, this is a horrible idea, why was it done in the first place? - update armature auto vertex group code to check for subsurf in modifier stack - fixed flip_subdivision to work with move to modifier stack - added copymenu_modifiers, can copy all modifiers or just data from first modifier of a certain type (not sure how to deal with multiple modifiers of same type... not a big issue though I think)
2005-07-27 20:16:41 +00:00
target->mode = md->mode;
if (mti->copyData)
mti->copyData(md, target);
}
- 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 07:25:43 +00:00
int modifier_couldBeCage(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
return ( (md->mode&eModifierMode_Realtime) &&
(md->mode&eModifierMode_Editmode) &&
(!mti->isDisabled || !mti->isDisabled(md)) &&
modifier_supportsMapping(md));
}
void modifier_setError(ModifierData *md, char *format, ...)
{
char buffer[2048];
va_list ap;
va_start(ap, format);
vsprintf(buffer, format, ap);
va_end(ap);
if (md->error)
MEM_freeN(md->error);
md->error = BLI_strdup(buffer);
allqueue(REDRAWBUTSEDIT, 0);
}
New: CrazySpace [tm] correction When Modifiers are used in Edit Mode to show the deformed result for editing, all actual coordinates Blender works with are still the ones from the original Cage. You can notice that with the Transform Widget or helper lines while transforming. Even worse, the actual transformations still happened on the original Cage as well, making it very hard to edit. That caused the feature to be named "CrazySpace" (baptized by Andy, afaik?). This commit calculates the deformation transformation per vertex, and inverse corrects it, so it's more intuitive editing this way. Unfortunately all the deformation features of Blender don't use matrices for defining deform, so the existing code cannot be re-used to retrieve the correct deformation matrix per vertex. The solution I found is based on calculating per face the transformation based on its first 3 vertices, and store this transformation averaged in the face's vertices. The solution can also only work on entire faces, because the full deform can only be retrieved using 3 vertices. (using 2 vertices will miss edge- aligned rotation, using 1 vertex can only retrieve translation). By deriving the deformations per face, small errors will still happen, especially on very low-poly Meshes with extreme deformations. The only alternative I know now, is providing each vertex in a mesh with 2 extreme small tangent vectors, which get deformed using the existing code as well. That will mess up the existing deformation code too much though, this solution has the benefit it works with each deform we can up with later too. Last note about CrazySpace: it can only be used to tweak Meshes. Do not even try to add vertices, extrude, or duplicate. Probably we should disable this... but preventing user errors isn't always power-user-friendly, eh. :)
2005-10-26 09:56:52 +00:00
/* used for buttons, to find out if the 'draw deformed in editmode' option is there */
/* also used in transform_conversion.c, to detect CrazySpace [tm] (2nd arg then is NULL) */
- 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-10 22:05:52 +00:00
int modifiers_getCageIndex(Object *ob, int *lastPossibleCageIndex_r)
- 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 07:25:43 +00: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-10 22:05:52 +00:00
ModifierData *md = ob->modifiers.first;
- 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 07:25:43 +00:00
int i, cageIndex = -1;
/* Find the last modifier acting on the cage. */
for (i=0; md; i++,md=md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if (!(md->mode&eModifierMode_Realtime)) continue;
if (!(md->mode&eModifierMode_Editmode)) continue;
if (mti->isDisabled && mti->isDisabled(md)) continue;
if (!(mti->flags&eModifierTypeFlag_SupportsEditmode)) continue;
if (!modifier_supportsMapping(md))
break;
if (lastPossibleCageIndex_r) *lastPossibleCageIndex_r = i;
if (md->mode&eModifierMode_OnCage)
cageIndex = i;
}
return cageIndex;
}
- switch to using softbody modifier, controls enabling but does not have variables, these are still in same place. enable button automatically makes/enables modifier. - changed hook to hook modifier conversion to happen on direct link, required to make sure we don't forget to free any memory for files saved with 2.38 that have hooks. - update modifier interface to enforce modifiers with the require-original- data flag to not move beyond deforming modifiers. - enforce only one softbody modifier allowed NOTE: Once again, no modifier stack for lattice yet means softbody for lattice does not work atm.
2005-08-11 02:23:52 +00:00
int modifiers_isSoftbodyEnabled(Object *ob)
{
ModifierData *md = modifiers_findByType(ob, eModifierType_Softbody);
/* Softbody not allowed in this situation, enforce! */
softbody <--> softbody collision make softbodies collide with objects patented to armatures (bones), lattices .. ) Softbody deflectors always use the new modifier stack. (thanks ZR) Softbody deflector code checks for identity of colliding objects so, there is no need to prohibit softbodies to be a deflector. So now you can put some soft balls in a box and see them bounce. see : http://wund.privat.t-online.de/bt/sb_sb_coll.blend A deflector cube parented to SB lattice: http://wund.privat.t-online.de/bt/sb_lattice.blend BM
2005-08-16 17:48:47 +00:00
/* if (md && ob->pd && ob->pd->deflect) { */
/* no reason for that any more BM */
if (0) {
- switch to using softbody modifier, controls enabling but does not have variables, these are still in same place. enable button automatically makes/enables modifier. - changed hook to hook modifier conversion to happen on direct link, required to make sure we don't forget to free any memory for files saved with 2.38 that have hooks. - update modifier interface to enforce modifiers with the require-original- data flag to not move beyond deforming modifiers. - enforce only one softbody modifier allowed NOTE: Once again, no modifier stack for lattice yet means softbody for lattice does not work atm.
2005-08-11 02:23:52 +00:00
md->mode &= ~(eModifierMode_Realtime|eModifierMode_Render|eModifierMode_Editmode);
md = NULL;
}
return (md && md->mode&(eModifierMode_Realtime|eModifierMode_Render));
}
- 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 03:31:33 +00:00
ModifierData *modifiers_getVirtualModifierList(Object *ob)
{
/* Kinda hacky, but should be fine since we are never
* reentrant and avoid free hassles.
*/
static ArmatureModifierData amd;
static CurveModifierData cmd;
static LatticeModifierData lmd;
static int init = 1;
if (init) {
ModifierData *md;
md = modifier_new(eModifierType_Armature);
amd = *((ArmatureModifierData*) md);
modifier_free(md);
md = modifier_new(eModifierType_Curve);
cmd = *((CurveModifierData*) md);
modifier_free(md);
md = modifier_new(eModifierType_Lattice);
lmd = *((LatticeModifierData*) md);
modifier_free(md);
amd.modifier.mode |= eModifierMode_Virtual;
cmd.modifier.mode |= eModifierMode_Virtual;
lmd.modifier.mode |= eModifierMode_Virtual;
init = 0;
}
if (ob->parent) {
if(ob->parent->type==OB_ARMATURE && ob->partype==PARSKEL) {
amd.object = ob->parent;
amd.modifier.next = ob->modifiers.first;
Another option for more Armature deform control; The "Use VGroup" or "Use Envelope" options now are in Modifier Panel for Armature deform. If Modifiers are in use, they override the Armature settings for it. (Cannot get rid of the Armature panel options yet, since Blender still allows parenting to be deforming too, which is displayed as a Virtual modifier now) This now allows to - for example - make a Envelope deform on a Lattice, and have same Armature use vertexgroups on Mesh. Next; vertexgroup option for Lattice & Curve deform
2005-10-20 16:31:46 +00:00
amd.deformflag= ((bArmature *)(ob->parent->data))->deformflag;
- 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 03:31:33 +00:00
return &amd.modifier;
} else if(ob->parent->type==OB_CURVE && ob->partype==PARSKEL) {
cmd.object = ob->parent;
cmd.modifier.next = ob->modifiers.first;
return &cmd.modifier;
} else if(ob->parent->type==OB_LATTICE && ob->partype==PARSKEL) {
lmd.object = ob->parent;
lmd.modifier.next = ob->modifiers.first;
return &lmd.modifier;
}
}
return ob->modifiers.first;
}
Basic support in modifiers_isDeformedByArmature for multiple armatures per mesh- use Selected armature object first, if no armatures are selected then return the last/only found armature.
2006-05-14 12:45:13 +00:00
/* Takes an object and returns its first selected armature, else just its armature
This should work for multiple armatures per object */
Fix for weight painting errors, as reported by Bassam. - Undo/Redo didn't work - Crash on using weightpaint with Armature-modifier (instead of parent). Note: checking if an object is being deformed cannot be simply done with checking for a parent anymore... for this a call in modifier.c has been added; modifiers_isDeformedByArmature(Object *). It even returns the Armature object pointer.
2005-09-07 18:07:24 +00:00
Object *modifiers_isDeformedByArmature(Object *ob)
- added modifiers_isDeformedByArmature function
2005-08-22 20:24:59 +00:00
{
- switch modifiers_isDeformedByArmature to also include virtual modifiers
2005-08-22 20:25:54 +00:00
ModifierData *md = modifiers_getVirtualModifierList(ob);
Basic support in modifiers_isDeformedByArmature for multiple armatures per mesh- use Selected armature object first, if no armatures are selected then return the last/only found armature.
2006-05-14 12:45:13 +00:00
ArmatureModifierData *amd= NULL;
/* return the first selected armaturem, this lets us use multiple armatures */
- switch modifiers_isDeformedByArmature to also include virtual modifiers
2005-08-22 20:25:54 +00:00
for (; md; md=md->next) {
- added modifiers_isDeformedByArmature function
2005-08-22 20:24:59 +00:00
if (md->type==eModifierType_Armature) {
Basic support in modifiers_isDeformedByArmature for multiple armatures per mesh- use Selected armature object first, if no armatures are selected then return the last/only found armature.
2006-05-14 12:45:13 +00:00
amd = (ArmatureModifierData*) md;
Fix #4243 Code that checked if mesh has armature modifier was reading NULL pointer (when modifier added without target, and facepaint started)
2006-05-29 13:59:18 +00:00
if (amd->object && (amd->object->flag & SELECT))
Basic support in modifiers_isDeformedByArmature for multiple armatures per mesh- use Selected armature object first, if no armatures are selected then return the last/only found armature.
2006-05-14 12:45:13 +00:00
return amd->object;
- added modifiers_isDeformedByArmature function
2005-08-22 20:24:59 +00:00
}
}
Basic support in modifiers_isDeformedByArmature for multiple armatures per mesh- use Selected armature object first, if no armatures are selected then return the last/only found armature.
2006-05-14 12:45:13 +00:00
if (amd) /* if were still here then return the last armature */
return amd->object;
Fix for weight painting errors, as reported by Bassam. - Undo/Redo didn't work - Crash on using weightpaint with Armature-modifier (instead of parent). Note: checking if an object is being deformed cannot be simply done with checking for a parent anymore... for this a call in modifier.c has been added; modifiers_isDeformedByArmature(Object *). It even returns the Armature object pointer.
2005-09-07 18:07:24 +00:00
return NULL;
New: CrazySpace [tm] correction When Modifiers are used in Edit Mode to show the deformed result for editing, all actual coordinates Blender works with are still the ones from the original Cage. You can notice that with the Transform Widget or helper lines while transforming. Even worse, the actual transformations still happened on the original Cage as well, making it very hard to edit. That caused the feature to be named "CrazySpace" (baptized by Andy, afaik?). This commit calculates the deformation transformation per vertex, and inverse corrects it, so it's more intuitive editing this way. Unfortunately all the deformation features of Blender don't use matrices for defining deform, so the existing code cannot be re-used to retrieve the correct deformation matrix per vertex. The solution I found is based on calculating per face the transformation based on its first 3 vertices, and store this transformation averaged in the face's vertices. The solution can also only work on entire faces, because the full deform can only be retrieved using 3 vertices. (using 2 vertices will miss edge- aligned rotation, using 1 vertex can only retrieve translation). By deriving the deformations per face, small errors will still happen, especially on very low-poly Meshes with extreme deformations. The only alternative I know now, is providing each vertex in a mesh with 2 extreme small tangent vectors, which get deformed using the existing code as well. That will mess up the existing deformation code too much though, this solution has the benefit it works with each deform we can up with later too. Last note about CrazySpace: it can only be used to tweak Meshes. Do not even try to add vertices, extrude, or duplicate. Probably we should disable this... but preventing user errors isn't always power-user-friendly, eh. :)
2005-10-26 09:56:52 +00:00
}
Multiple armatures<>mesh objects now work with name flipping. previously would only work if the armature was the first in the meshes modifier list, in that case the armature would be name flipped but the mesh would not)
2006-05-04 00:59:02 +00:00
int modifiers_usesArmature(Object *ob, bArmature *arm)
{
ModifierData *md = modifiers_getVirtualModifierList(ob);
for (; md; md=md->next) {
if (md->type==eModifierType_Armature) {
ArmatureModifierData *amd = (ArmatureModifierData*) md;
if (amd->object->data==arm)
return 1;
}
}
=== BPY === Proper typed return. NULL != 0
2006-05-14 14:14:32 +00:00
return 0;
Multiple armatures<>mesh objects now work with name flipping. previously would only work if the armature was the first in the meshes modifier list, in that case the armature would be name flipped but the mesh would not)
2006-05-04 00:59:02 +00:00
}
New: CrazySpace [tm] correction When Modifiers are used in Edit Mode to show the deformed result for editing, all actual coordinates Blender works with are still the ones from the original Cage. You can notice that with the Transform Widget or helper lines while transforming. Even worse, the actual transformations still happened on the original Cage as well, making it very hard to edit. That caused the feature to be named "CrazySpace" (baptized by Andy, afaik?). This commit calculates the deformation transformation per vertex, and inverse corrects it, so it's more intuitive editing this way. Unfortunately all the deformation features of Blender don't use matrices for defining deform, so the existing code cannot be re-used to retrieve the correct deformation matrix per vertex. The solution I found is based on calculating per face the transformation based on its first 3 vertices, and store this transformation averaged in the face's vertices. The solution can also only work on entire faces, because the full deform can only be retrieved using 3 vertices. (using 2 vertices will miss edge- aligned rotation, using 1 vertex can only retrieve translation). By deriving the deformations per face, small errors will still happen, especially on very low-poly Meshes with extreme deformations. The only alternative I know now, is providing each vertex in a mesh with 2 extreme small tangent vectors, which get deformed using the existing code as well. That will mess up the existing deformation code too much though, this solution has the benefit it works with each deform we can up with later too. Last note about CrazySpace: it can only be used to tweak Meshes. Do not even try to add vertices, extrude, or duplicate. Probably we should disable this... but preventing user errors isn't always power-user-friendly, eh. :)
2005-10-26 09:56:52 +00:00
int modifiers_isDeformed(Object *ob)
{
ModifierData *md = modifiers_getVirtualModifierList(ob);
for (; md; md=md->next) {
Orange bugreport; disabling (with small icon button) a deforming modifier for EditMode, the CrazySpace correction still worked. Made it check for the modifier mode flag.
2005-11-30 20:22:27 +00:00
if(ob==G.obedit && (md->mode & eModifierMode_Editmode)==0);
else {
if (md->type==eModifierType_Armature)
return 1;
if (md->type==eModifierType_Curve)
return 1;
if (md->type==eModifierType_Lattice)
return 1;
}
New: CrazySpace [tm] correction When Modifiers are used in Edit Mode to show the deformed result for editing, all actual coordinates Blender works with are still the ones from the original Cage. You can notice that with the Transform Widget or helper lines while transforming. Even worse, the actual transformations still happened on the original Cage as well, making it very hard to edit. That caused the feature to be named "CrazySpace" (baptized by Andy, afaik?). This commit calculates the deformation transformation per vertex, and inverse corrects it, so it's more intuitive editing this way. Unfortunately all the deformation features of Blender don't use matrices for defining deform, so the existing code cannot be re-used to retrieve the correct deformation matrix per vertex. The solution I found is based on calculating per face the transformation based on its first 3 vertices, and store this transformation averaged in the face's vertices. The solution can also only work on entire faces, because the full deform can only be retrieved using 3 vertices. (using 2 vertices will miss edge- aligned rotation, using 1 vertex can only retrieve translation). By deriving the deformations per face, small errors will still happen, especially on very low-poly Meshes with extreme deformations. The only alternative I know now, is providing each vertex in a mesh with 2 extreme small tangent vectors, which get deformed using the existing code as well. That will mess up the existing deformation code too much though, this solution has the benefit it works with each deform we can up with later too. Last note about CrazySpace: it can only be used to tweak Meshes. Do not even try to add vertices, extrude, or duplicate. Probably we should disable this... but preventing user errors isn't always power-user-friendly, eh. :)
2005-10-26 09:56:52 +00:00
}
return 0;
}
Copy Permalink