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

786 lines
22 KiB
C
Raw Normal View History

/*
2011-10-10 09:38:02 +00:00
* ***** BEGIN GPL LICENSE BLOCK *****
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2005 by the Blender Foundation.
* All rights reserved.
*
* Contributor(s): Daniel Dunbar
* Ton Roosendaal,
* Ben Batt,
* Brecht Van Lommel,
* Campbell Barton
*
* ***** END GPL LICENSE BLOCK *****
*
* Modifier stack implementation.
*
* BKE_modifier.h contains the function prototypes for this file.
*
*/
2011-02-27 20:40:57 +00:00
/** \file blender/blenkernel/intern/modifier.c
* \ingroup bke
*/
#include <stdlib.h>
#include <stddef.h>
#include <string.h>
#include <stdarg.h>
#include <math.h>
#include <float.h>
#include "MEM_guardedalloc.h"
#include "DNA_armature_types.h"
#include "DNA_object_types.h"
#include "DNA_meshdata_types.h"
#include "BLI_utildefines.h"
#include "BLI_path_util.h"
#include "BLI_listbase.h"
2011-10-22 01:53:35 +00:00
#include "BLI_linklist.h"
#include "BLI_string.h"
#include "BLF_translation.h"
#include "BKE_cloth.h"
#include "BKE_key.h"
#include "BKE_multires.h"
#include "BKE_DerivedMesh.h"
/* may move these, only for modifier_path_relbase */
#include "BKE_global.h" /* ugh, G.main->name only */
#include "BKE_main.h"
/* end */
#include "MOD_modifiertypes.h"
static ModifierTypeInfo *modifier_types[NUM_MODIFIER_TYPES] = {NULL};
static VirtualModifierData virtualModifierCommonData;
void BKE_modifier_init(void)
{
ModifierData *md;
/* Initialize modifier types */
modifier_type_init(modifier_types); /* MOD_utils.c */
/* Initialize global cmmon storage used for virtual modifier list */
md = modifier_new(eModifierType_Armature);
virtualModifierCommonData.amd = *((ArmatureModifierData *) md);
modifier_free(md);
md = modifier_new(eModifierType_Curve);
virtualModifierCommonData.cmd = *((CurveModifierData *) md);
modifier_free(md);
md = modifier_new(eModifierType_Lattice);
virtualModifierCommonData.lmd = *((LatticeModifierData *) md);
modifier_free(md);
md = modifier_new(eModifierType_ShapeKey);
virtualModifierCommonData.smd = *((ShapeKeyModifierData *) md);
modifier_free(md);
virtualModifierCommonData.amd.modifier.mode |= eModifierMode_Virtual;
virtualModifierCommonData.cmd.modifier.mode |= eModifierMode_Virtual;
virtualModifierCommonData.lmd.modifier.mode |= eModifierMode_Virtual;
virtualModifierCommonData.smd.modifier.mode |= eModifierMode_Virtual;
}
ModifierTypeInfo *modifierType_getInfo(ModifierType type)
{
/* type unsigned, no need to check < 0 */
if (type < NUM_MODIFIER_TYPES && modifier_types[type]->name[0] != '\0') {
return modifier_types[type];
}
else {
return NULL;
}
}
/***/
- shuffled editmesh derived function name/function - added ModifierTypeInfo.freeData function - added modifier_{new,free] utility function - added ccgSubSurf_getUseAgeCounts to query info - removed subsurf modifier faking (ME_SUBSURF flag is no longer valid). subsurf modifier gets converted on file load although there is obscure linked mesh situation where this can go wrong, will fix shortly. this also means that some places in the code that test/copy subsurf settings are broken for the time being. - shuffled modifier calculation to be simpler. note that all modifiers are currently disabled in editmode (including subsurf). don't worry, will return shortly. - bug fix, build modifier didn't randomize meshes with only verts - cleaned up subsurf_ccg and adapted for future editmode modifier work - added editmesh.derived{Cage,Final}, not used yet - added SubsurfModifierData.{mCache,emCache}, will be used to cache subsurf instead of caching in derivedmesh itself - removed old subsurf buttons - added do_modifiers_buttons to handle modifier events - removed count_object counting of modifier (subsurfed) objects... this would be nice to add back at some point but requires care. probably requires rewrite of counting system. New feature: Incremental Subsurf in Object Mode The previous release introduce incremental subsurf calculation during editmode but it was not turned on during object mode. In general it does not make sense to have it always enabled during object mode because it requires caching a fair amount of information about the mesh which is a waste of memory unless the mesh is often recalculated. However, for mesh's that have subsurfed armatures for example, or that have other modifiers so that the mesh is essentially changing on every frame, it makes a lot of sense to keep the subsurf'd object around and that is what the new incremental subsurf modifier toggle is for. The intent is that the user will enable this option for (a) a mesh that is currently under active editing or (b) a mesh that is heavily updated in the scene, such as a character. I will try to write more about this feature for release, because it has advantages and disadvantages that are not immediately obvious (the first user reaction will be to turn it on for ever object, which is probably not correct).
2005-07-21 20:30:33 +00:00
ModifierData *modifier_new(int type)
{
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);
/* note, this name must be made unique later */
BLI_strncpy(md->name, DATA_(mti->name), sizeof(md->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;
2012-05-09 09:24:15 +00:00
md->mode = eModifierMode_Realtime | eModifierMode_Render | eModifierMode_Expanded;
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)
{
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);
}
void modifier_unique_name(ListBase *modifiers, ModifierData *md)
{
if (modifiers && md) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
BLI_uniquename(modifiers, md, DATA_(mti->name), '.', offsetof(ModifierData, name), sizeof(md->name));
}
}
bool modifier_dependsOnTime(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
return mti->dependsOnTime && mti->dependsOnTime(md);
}
bool modifier_supportsMapping(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
2012-05-06 17:22:54 +00:00
return (mti->type == eModifierTypeType_OnlyDeform ||
(mti->flags & eModifierTypeFlag_SupportsMapping));
}
bool modifier_isPreview(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if (!(mti->flags & eModifierTypeFlag_UsesPreview))
return FALSE;
if (md->mode & eModifierMode_Realtime)
return TRUE;
return FALSE;
}
ModifierData *modifiers_findByType(Object *ob, ModifierType type)
{
ModifierData *md = ob->modifiers.first;
2012-05-06 17:22:54 +00:00
for (; md; md = md->next)
if (md->type == type)
break;
return md;
}
ModifierData *modifiers_findByName(Object *ob, const char *name)
{
return BLI_findstring(&(ob->modifiers), name, offsetof(ModifierData, name));
}
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
{
ModifierData *md = ob->modifiers.first;
2011-01-08 12:43:44 +00:00
/* 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
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
- 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);
md->error = NULL;
2011-01-08 12:43:44 +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
}
}
}
void modifiers_foreachObjectLink(Object *ob, ObjectWalkFunc walk,
2012-05-06 17:22:54 +00:00
void *userData)
{
ModifierData *md = ob->modifiers.first;
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if (mti->foreachObjectLink)
mti->foreachObjectLink(md, ob, walk, userData);
}
}
void modifiers_foreachIDLink(Object *ob, IDWalkFunc walk, void *userData)
{
ModifierData *md = ob->modifiers.first;
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if (mti->foreachIDLink) mti->foreachIDLink(md, ob, walk, userData);
else if (mti->foreachObjectLink) {
/* each Object can masquerade as an ID, so this should be OK */
ObjectWalkFunc fp = (ObjectWalkFunc)walk;
mti->foreachObjectLink(md, ob, fp, 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
}
void modifiers_foreachTexLink(Object *ob, TexWalkFunc walk, void *userData)
{
ModifierData *md = ob->modifiers.first;
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
if (mti->foreachTexLink)
mti->foreachTexLink(md, ob, walk, userData);
}
}
/* callback's can use this
* to avoid copying every member.
*/
void modifier_copyData_generic(const ModifierData *md_src, ModifierData *md_dst)
{
ModifierTypeInfo *mti = modifierType_getInfo(md_src->type);
const size_t data_size = sizeof(ModifierData);
const char *md_src_data = ((char *)md_src) + data_size;
char *md_dst_data = ((char *)md_dst) + data_size;
BLI_assert(data_size <= (size_t)mti->structSize);
memcpy(md_dst_data, md_src_data, (size_t)mti->structSize - data_size);
}
void modifier_copyData(ModifierData *md, ModifierData *target)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
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
bool modifier_supportsCage(struct Scene *scene, ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
md->scene = scene;
return ((!mti->isDisabled || !mti->isDisabled(md, 0)) &&
(mti->flags & eModifierTypeFlag_SupportsEditmode) &&
modifier_supportsMapping(md));
}
bool modifier_couldBeCage(struct Scene *scene, ModifierData *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
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
2012-05-06 17:22:54 +00:00
md->scene = scene;
2012-05-06 17:22:54 +00:00
return ((md->mode & eModifierMode_Realtime) &&
(md->mode & eModifierMode_Editmode) &&
(!mti->isDisabled || !mti->isDisabled(md, 0)) &&
modifier_supportsMapping(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
}
bool modifier_isSameTopology(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
return ELEM(mti->type, eModifierTypeType_OnlyDeform, eModifierTypeType_NonGeometrical);
}
bool modifier_isNonGeometrical(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
return (mti->type == eModifierTypeType_NonGeometrical);
}
void modifier_setError(ModifierData *md, const char *_format, ...)
- 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
{
char buffer[512];
- 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
va_list ap;
const char *format = TIP_(_format);
- 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
va_start(ap, _format);
vsnprintf(buffer, sizeof(buffer), format, ap);
- 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
va_end(ap);
2012-05-06 17:22:54 +00:00
buffer[sizeof(buffer) - 1] = '\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
if (md->error)
MEM_freeN(md->error);
md->error = BLI_strdup(buffer);
}
/* 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)
* also used for some mesh tools to give warnings
*/
int modifiers_getCageIndex(struct Scene *scene, Object *ob, int *lastPossibleCageIndex_r, int virtual_)
- 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
{
VirtualModifierData virtualModifierData;
ModifierData *md = (virtual_) ? modifiers_getVirtualModifierList(ob, &virtualModifierData) : 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;
if (lastPossibleCageIndex_r) {
/* ensure the value is initialized */
2012-05-06 17:22:54 +00:00
*lastPossibleCageIndex_r = -1;
}
/* Find the last modifier acting on the cage. */
2012-05-06 17:22:54 +00:00
for (i = 0; md; i++, md = md->next) {
- 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
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
2012-05-06 17:22:54 +00:00
md->scene = scene;
if (mti->isDisabled && mti->isDisabled(md, 0)) continue;
if (!(mti->flags & eModifierTypeFlag_SupportsEditmode)) continue;
if (md->mode & eModifierMode_DisableTemporary) continue;
- 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 (!modifier_supportsMapping(md))
break;
if (lastPossibleCageIndex_r) *lastPossibleCageIndex_r = i;
if (!(md->mode & eModifierMode_Realtime)) continue;
if (!(md->mode & eModifierMode_Editmode)) continue;
if (md->mode & eModifierMode_OnCage)
- 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
cageIndex = i;
}
return cageIndex;
}
bool modifiers_isSoftbodyEnabled(Object *ob)
{
ModifierData *md = modifiers_findByType(ob, eModifierType_Softbody);
return (md && md->mode & (eModifierMode_Realtime | eModifierMode_Render));
}
bool modifiers_isClothEnabled(Object *ob)
{
ModifierData *md = modifiers_findByType(ob, eModifierType_Cloth);
return (md && md->mode & (eModifierMode_Realtime | eModifierMode_Render));
}
bool modifiers_isModifierEnabled(Object *ob, int modifierType)
{
ModifierData *md = modifiers_findByType(ob, modifierType);
return (md && md->mode & (eModifierMode_Realtime | eModifierMode_Render));
}
bool modifiers_isParticleEnabled(Object *ob)
{
ModifierData *md = modifiers_findByType(ob, eModifierType_ParticleSystem);
return (md && md->mode & (eModifierMode_Realtime | eModifierMode_Render));
}
bool modifier_isEnabled(struct Scene *scene, ModifierData *md, int required_mode)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
2012-05-06 17:22:54 +00:00
md->scene = scene;
if ((md->mode & required_mode) != required_mode) return 0;
if (mti->isDisabled && mti->isDisabled(md, required_mode == eModifierMode_Render)) return 0;
if (md->mode & eModifierMode_DisableTemporary) return 0;
if (required_mode & eModifierMode_Editmode)
if (!(mti->flags & eModifierTypeFlag_SupportsEditmode)) return 0;
return 1;
}
CDMaskLink *modifiers_calcDataMasks(struct Scene *scene, Object *ob, ModifierData *md,
CustomDataMask dataMask, int required_mode,
ModifierData *previewmd, CustomDataMask previewmask)
{
CDMaskLink *dataMasks = NULL;
CDMaskLink *curr, *prev;
/* build a list of modifier data requirements in reverse order */
for (; md; md = md->next) {
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
curr = MEM_callocN(sizeof(CDMaskLink), "CDMaskLink");
if (modifier_isEnabled(scene, md, required_mode)) {
if (mti->requiredDataMask)
curr->mask = mti->requiredDataMask(ob, md);
if (previewmd == md) {
curr->mask |= previewmask;
}
}
/* prepend new datamask */
curr->next = dataMasks;
dataMasks = curr;
}
/* build the list of required data masks - each mask in the list must
* include all elements of the masks that follow it
*
* note the list is currently in reverse order, so "masks that follow it"
* actually means "masks that precede it" at the moment
*/
for (curr = dataMasks, prev = NULL; curr; prev = curr, curr = curr->next) {
if (prev) {
CustomDataMask prev_mask = prev->mask;
CustomDataMask curr_mask = curr->mask;
curr->mask = curr_mask | prev_mask;
}
else {
CustomDataMask curr_mask = curr->mask;
curr->mask = curr_mask | dataMask;
}
}
/* reverse the list so it's in the correct order */
2012-05-06 17:22:54 +00:00
BLI_linklist_reverse((LinkNode **)&dataMasks);
return dataMasks;
}
ModifierData *modifiers_getLastPreview(struct Scene *scene, ModifierData *md, int required_mode)
{
ModifierData *tmp_md = NULL;
if ((required_mode & ~eModifierMode_Editmode) != eModifierMode_Realtime)
return tmp_md;
/* Find the latest modifier in stack generating preview. */
for (; md; md = md->next) {
if (modifier_isEnabled(scene, md, required_mode) && modifier_isPreview(md))
tmp_md = md;
}
return tmp_md;
}
/* NOTE: This is to support old files from before Blender supported modifiers,
* in some cases versioning code updates these so for new files this will
* return an empty list. */
ModifierData *modifiers_getVirtualModifierList(Object *ob, VirtualModifierData *virtualModifierData)
{
ModifierData *md;
md = ob->modifiers.first;
*virtualModifierData = virtualModifierCommonData;
if (ob->parent) {
2012-05-06 17:22:54 +00:00
if (ob->parent->type == OB_ARMATURE && ob->partype == PARSKEL) {
virtualModifierData->amd.object = ob->parent;
virtualModifierData->amd.modifier.next = md;
virtualModifierData->amd.deformflag = ((bArmature *)(ob->parent->data))->deformflag;
md = &virtualModifierData->amd.modifier;
}
2012-05-06 17:22:54 +00:00
else if (ob->parent->type == OB_CURVE && ob->partype == PARSKEL) {
virtualModifierData->cmd.object = ob->parent;
virtualModifierData->cmd.defaxis = ob->trackflag + 1;
virtualModifierData->cmd.modifier.next = md;
md = &virtualModifierData->cmd.modifier;
}
2012-05-06 17:22:54 +00:00
else if (ob->parent->type == OB_LATTICE && ob->partype == PARSKEL) {
virtualModifierData->lmd.object = ob->parent;
virtualModifierData->lmd.modifier.next = md;
md = &virtualModifierData->lmd.modifier;
}
}
/* shape key modifier, not yet for curves */
if (ELEM(ob->type, OB_MESH, OB_LATTICE) && BKE_key_from_object(ob)) {
if (ob->type == OB_MESH && (ob->shapeflag & OB_SHAPE_EDIT_MODE))
virtualModifierData->smd.modifier.mode |= eModifierMode_Editmode | eModifierMode_OnCage;
else
virtualModifierData->smd.modifier.mode &= ~eModifierMode_Editmode | eModifierMode_OnCage;
virtualModifierData->smd.modifier.next = md;
md = &virtualModifierData->smd.modifier;
}
return md;
}
/* Takes an object and returns its first selected armature, else just its armature
* This should work for multiple armatures per object
*/
Object *modifiers_isDeformedByArmature(Object *ob)
{
VirtualModifierData virtualModifierData;
ModifierData *md = modifiers_getVirtualModifierList(ob, &virtualModifierData);
2012-05-06 17:22:54 +00:00
ArmatureModifierData *amd = NULL;
/* return the first selected armature, this lets us use multiple armatures */
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
if (md->type == eModifierType_Armature) {
amd = (ArmatureModifierData *) md;
if (amd->object && (amd->object->flag & SELECT))
return amd->object;
}
}
if (amd) /* if were still here then return the last armature */
return amd->object;
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
}
/* Takes an object and returns its first selected lattice, else just its lattice
* This should work for multiple lattices per object
*/
Object *modifiers_isDeformedByLattice(Object *ob)
{
VirtualModifierData virtualModifierData;
ModifierData *md = modifiers_getVirtualModifierList(ob, &virtualModifierData);
2012-05-06 17:22:54 +00:00
LatticeModifierData *lmd = NULL;
/* return the first selected lattice, this lets us use multiple lattices */
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
if (md->type == eModifierType_Lattice) {
lmd = (LatticeModifierData *) md;
if (lmd->object && (lmd->object->flag & SELECT))
return lmd->object;
}
}
if (lmd) /* if were still here then return the last lattice */
return lmd->object;
return NULL;
}
/* Takes an object and returns its first selected curve, else just its curve
* This should work for multiple curves per object
*/
Object *modifiers_isDeformedByCurve(Object *ob)
{
VirtualModifierData virtualModifierData;
ModifierData *md = modifiers_getVirtualModifierList(ob, &virtualModifierData);
CurveModifierData *cmd = NULL;
/* return the first selected curve, this lets us use multiple curves */
for (; md; md = md->next) {
if (md->type == eModifierType_Curve) {
cmd = (CurveModifierData *) md;
if (cmd->object && (cmd->object->flag & SELECT))
return cmd->object;
}
}
if (cmd) /* if were still here then return the last curve */
return cmd->object;
return NULL;
}
bool modifiers_usesArmature(Object *ob, bArmature *arm)
{
VirtualModifierData virtualModifierData;
ModifierData *md = modifiers_getVirtualModifierList(ob, &virtualModifierData);
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
if (md->type == eModifierType_Armature) {
ArmatureModifierData *amd = (ArmatureModifierData *) md;
if (amd->object && amd->object->data == arm)
return true;
}
}
return false;
}
bool modifier_isCorrectableDeformed(ModifierData *md)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
return (mti->deformMatricesEM != NULL);
}
bool modifiers_isCorrectableDeformed(struct Scene *scene, Object *ob)
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
{
VirtualModifierData virtualModifierData;
ModifierData *md = modifiers_getVirtualModifierList(ob, &virtualModifierData);
int required_mode = eModifierMode_Realtime;
if (ob->mode == OB_MODE_EDIT)
required_mode |= eModifierMode_Editmode;
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
2012-05-06 17:22:54 +00:00
for (; md; md = md->next) {
if (!modifier_isEnabled(scene, md, required_mode)) {
2012-10-07 09:48:59 +00:00
/* pass */
}
else if (modifier_isCorrectableDeformed(md)) {
return true;
2012-10-07 09:48:59 +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
}
return false;
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
}
/* Check whether the given object has a modifier in its stack that uses WEIGHT_MCOL CD layer
* to preview something... Used by DynamicPaint and WeightVG currently. */
bool modifiers_isPreview(Object *ob)
{
ModifierData *md = ob->modifiers.first;
for (; md; md = md->next) {
if (modifier_isPreview(md))
return true;
}
return false;
}
void modifier_freeTemporaryData(ModifierData *md)
{
if (md->type == eModifierType_Armature) {
2012-05-06 17:22:54 +00:00
ArmatureModifierData *amd = (ArmatureModifierData *)md;
if (amd->prevCos) {
MEM_freeN(amd->prevCos);
2012-05-06 17:22:54 +00:00
amd->prevCos = NULL;
}
}
}
/* ensure modifier correctness when changing ob->data */
void test_object_modifiers(Object *ob)
{
ModifierData *md;
/* just multires checked for now, since only multires
* modifies mesh data */
if (ob->type != OB_MESH) return;
for (md = ob->modifiers.first; md; md = md->next) {
if (md->type == eModifierType_Multires) {
2012-05-06 17:22:54 +00:00
MultiresModifierData *mmd = (MultiresModifierData *)md;
multiresModifier_set_levels_from_disps(mmd, ob);
}
}
}
/* where should this go?, it doesnt fit well anywhere :S - campbell */
/* elubie: changed this to default to the same dir as the render output
* to prevent saving to C:\ on Windows */
/* campbell: logic behind this...
*
* - if the ID is from a library, return library path
* - else if the file has been saved return the blend file path.
2012-03-18 07:38:51 +00:00
* - else if the file isn't saved and the ID isn't from a library, return the temp dir.
*/
const char *modifier_path_relbase(Object *ob)
{
if (G.relbase_valid || ob->id.lib) {
return ID_BLEND_PATH(G.main, &ob->id);
}
else {
/* last resort, better then using "" which resolves to the current
* working directory */
return BLI_temporary_dir();
}
}
/* initializes the path with either */
void modifier_path_init(char *path, int path_maxlen, const char *name)
{
/* elubie: changed this to default to the same dir as the render output
* to prevent saving to C:\ on Windows */
BLI_join_dirfile(path, path_maxlen,
G.relbase_valid ? "//" : BLI_temporary_dir(),
name);
}
/* wrapper around ModifierTypeInfo.applyModifier that ensures valid normals */
struct DerivedMesh *modwrap_applyModifier(
ModifierData *md, Object *ob,
struct DerivedMesh *dm,
ModifierApplyFlag flag)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
BLI_assert(CustomData_has_layer(&dm->polyData, CD_NORMAL) == false);
if (mti->dependsOnNormals && mti->dependsOnNormals(md)) {
DM_ensure_normals(dm);
}
return mti->applyModifier(md, ob, dm, flag);
}
struct DerivedMesh *modwrap_applyModifierEM(
ModifierData *md, Object *ob,
struct BMEditMesh *em,
DerivedMesh *dm,
ModifierApplyFlag flag)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
BLI_assert(CustomData_has_layer(&dm->polyData, CD_NORMAL) == false);
if (mti->dependsOnNormals && mti->dependsOnNormals(md)) {
DM_ensure_normals(dm);
}
return mti->applyModifierEM(md, ob, em, dm, flag);
}
void modwrap_deformVerts(
ModifierData *md, Object *ob,
DerivedMesh *dm,
float (*vertexCos)[3], int numVerts,
ModifierApplyFlag flag)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
BLI_assert(!dm || CustomData_has_layer(&dm->polyData, CD_NORMAL) == false);
if (dm && mti->dependsOnNormals && mti->dependsOnNormals(md)) {
DM_ensure_normals(dm);
}
mti->deformVerts(md, ob, dm, vertexCos, numVerts, flag);
}
void modwrap_deformVertsEM(
ModifierData *md, Object *ob,
struct BMEditMesh *em, DerivedMesh *dm,
float (*vertexCos)[3], int numVerts)
{
ModifierTypeInfo *mti = modifierType_getInfo(md->type);
BLI_assert(!dm || CustomData_has_layer(&dm->polyData, CD_NORMAL) == false);
if (dm && mti->dependsOnNormals && mti->dependsOnNormals(md)) {
DM_ensure_normals(dm);
}
mti->deformVertsEM(md, ob, em, dm, vertexCos, numVerts);
}
/* end modifier callback wrappers */