Files
test/source/blender/modifiers/intern/MOD_dynamicpaint.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

241 lines
7.5 KiB
C
Raw Normal View History

/*
* 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
2020-05-09 17:14:35 +10:00
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*/
/** \file
* \ingroup modifiers
*/
#include <stddef.h>
#include <string.h>
#include "BLI_listbase.h"
#include "BLI_utildefines.h"
#include "BLT_translation.h"
#include "DNA_defaults.h"
#include "DNA_dynamicpaint_types.h"
#include "DNA_mesh_types.h"
#include "DNA_object_force_types.h"
#include "DNA_object_types.h"
#include "DNA_scene_types.h"
#include "DNA_screen_types.h"
#include "BKE_context.h"
#include "BKE_dynamicpaint.h"
2017-04-21 14:28:23 +02:00
#include "BKE_layer.h"
#include "BKE_lib_query.h"
#include "BKE_mesh.h"
#include "BKE_modifier.h"
#include "BKE_screen.h"
#include "UI_interface.h"
#include "UI_resources.h"
#include "RNA_access.h"
#include "DEG_depsgraph.h"
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
#include "DEG_depsgraph_build.h"
#include "DEG_depsgraph_physics.h"
#include "DEG_depsgraph_query.h"
#include "MOD_modifiertypes.h"
#include "MOD_ui_common.h"
2018-06-17 17:04:27 +02:00
static void initData(ModifierData *md)
{
2012-05-06 13:38:33 +00:00
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
2018-06-17 17:04:27 +02:00
BLI_assert(MEMCMP_STRUCT_AFTER_IS_ZERO(pmd, modifier));
MEMCPY_STRUCT_AFTER(pmd, DNA_struct_default_get(DynamicPaintModifierData), modifier);
}
static void copyData(const ModifierData *md, ModifierData *target, const int flag)
{
const DynamicPaintModifierData *pmd = (const DynamicPaintModifierData *)md;
2012-05-06 13:38:33 +00:00
DynamicPaintModifierData *tpmd = (DynamicPaintModifierData *)target;
2018-06-17 17:04:27 +02:00
dynamicPaint_Modifier_copy(pmd, tpmd, flag);
}
static void freeRuntimeData(void *runtime_data_v)
{
if (runtime_data_v == NULL) {
return;
}
DynamicPaintRuntime *runtime_data = (DynamicPaintRuntime *)runtime_data_v;
dynamicPaint_Modifier_free_runtime(runtime_data);
}
static void freeData(ModifierData *md)
{
2012-05-06 13:38:33 +00:00
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
dynamicPaint_Modifier_free(pmd);
}
static void requiredDataMask(Object *UNUSED(ob),
ModifierData *md,
CustomData_MeshMasks *r_cddata_masks)
{
2012-05-06 13:38:33 +00:00
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
if (pmd->canvas) {
DynamicPaintSurface *surface = pmd->canvas->surfaces.first;
2012-05-06 13:38:33 +00:00
for (; surface; surface = surface->next) {
/* tface */
2018-06-17 17:04:27 +02:00
if (surface->format == MOD_DPAINT_SURFACE_F_IMAGESEQ ||
surface->init_color_type == MOD_DPAINT_INITIAL_TEXTURE) {
r_cddata_masks->lmask |= CD_MASK_MLOOPUV;
}
/* mcol */
if (surface->type == MOD_DPAINT_SURFACE_T_PAINT ||
surface->init_color_type == MOD_DPAINT_INITIAL_VERTEXCOLOR) {
r_cddata_masks->lmask |= CD_MASK_MLOOPCOL;
}
/* CD_MDEFORMVERT */
if (surface->type == MOD_DPAINT_SURFACE_T_WEIGHT) {
r_cddata_masks->vmask |= CD_MASK_MDEFORMVERT;
}
}
}
}
static Mesh *modifyMesh(ModifierData *md, const ModifierEvalContext *ctx, Mesh *mesh)
{
2012-05-06 13:38:33 +00:00
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
2021-03-18 09:35:12 +11:00
/* Don't apply dynamic paint on ORCO mesh stack. */
if (!(ctx->flag & MOD_APPLY_ORCO)) {
Scene *scene = DEG_get_evaluated_scene(ctx->depsgraph);
return dynamicPaint_Modifier_do(pmd, ctx->depsgraph, scene, ctx->object, mesh);
}
return mesh;
}
static bool is_brush_cb(Object *UNUSED(ob), ModifierData *md)
Fix depsgraph to compute more accurate links for collision & force. Current implementation more or less indiscriminately links physics objects to colliders and forces, ignoring precise details of layer checks and collider groups. The new depsgraph seemed to lack some such links at all. The relevant code in modifiers suffers from a lot of duplication. Different physics simulations use independent implementations of collision and similar things, which results in a lot of variance: * Cloth collides with objects on same or visible layer with dupli. * Softbody collides with objects on same layer without dupli. * Non-hair particles collide on same layer with dupli. * Smoke uses same code as cloth, but needs different modifier. * Dynamic paint "collides" with brushes on any layer without dupli. Force fields with absorption also imply dependency on colliders: * For most systems, colliders are selected from same layer as field. * For non-hair particles, it uses the same exact set as the particles. As a special quirk, smoke ignores smoke flow force fields; on the other hand dependency on such field implies dependency on the smoke domain. This introduces two utility functions each for old and new depsgraph that are flexible enough to handle all these variations, and uses them to handle particles, cloth, smoke, softbody and dynpaint. One thing to watch out for is that depsgraph code shouldn't rely on any properties that don't cause a graph rebuild when changed. This was violated in the original code that was building force field links, while taking zero field weights into account. This change may cause new dependency cycles in cases where necessary dependencies were missing, but may also remove cycles in situations where unnecessary links were previously created. It's also now possible to solve some cycles by switching to explicit groups, since they are now properly taken into account for dependencies. Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
{
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
return (pmd->brush != NULL && pmd->type == MOD_DYNAMICPAINT_TYPE_BRUSH);
Fix depsgraph to compute more accurate links for collision & force. Current implementation more or less indiscriminately links physics objects to colliders and forces, ignoring precise details of layer checks and collider groups. The new depsgraph seemed to lack some such links at all. The relevant code in modifiers suffers from a lot of duplication. Different physics simulations use independent implementations of collision and similar things, which results in a lot of variance: * Cloth collides with objects on same or visible layer with dupli. * Softbody collides with objects on same layer without dupli. * Non-hair particles collide on same layer with dupli. * Smoke uses same code as cloth, but needs different modifier. * Dynamic paint "collides" with brushes on any layer without dupli. Force fields with absorption also imply dependency on colliders: * For most systems, colliders are selected from same layer as field. * For non-hair particles, it uses the same exact set as the particles. As a special quirk, smoke ignores smoke flow force fields; on the other hand dependency on such field implies dependency on the smoke domain. This introduces two utility functions each for old and new depsgraph that are flexible enough to handle all these variations, and uses them to handle particles, cloth, smoke, softbody and dynpaint. One thing to watch out for is that depsgraph code shouldn't rely on any properties that don't cause a graph rebuild when changed. This was violated in the original code that was building force field links, while taking zero field weights into account. This change may cause new dependency cycles in cases where necessary dependencies were missing, but may also remove cycles in situations where unnecessary links were previously created. It's also now possible to solve some cycles by switching to explicit groups, since they are now properly taken into account for dependencies. Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
}
static void updateDepsgraph(ModifierData *md, const ModifierUpdateDepsgraphContext *ctx)
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
{
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
/* Add relation from canvases to all brush objects. */
if (pmd->canvas != NULL && pmd->type == MOD_DYNAMICPAINT_TYPE_CANVAS) {
LISTBASE_FOREACH (DynamicPaintSurface *, surface, &pmd->canvas->surfaces) {
Fix depsgraph to compute more accurate links for collision & force. Current implementation more or less indiscriminately links physics objects to colliders and forces, ignoring precise details of layer checks and collider groups. The new depsgraph seemed to lack some such links at all. The relevant code in modifiers suffers from a lot of duplication. Different physics simulations use independent implementations of collision and similar things, which results in a lot of variance: * Cloth collides with objects on same or visible layer with dupli. * Softbody collides with objects on same layer without dupli. * Non-hair particles collide on same layer with dupli. * Smoke uses same code as cloth, but needs different modifier. * Dynamic paint "collides" with brushes on any layer without dupli. Force fields with absorption also imply dependency on colliders: * For most systems, colliders are selected from same layer as field. * For non-hair particles, it uses the same exact set as the particles. As a special quirk, smoke ignores smoke flow force fields; on the other hand dependency on such field implies dependency on the smoke domain. This introduces two utility functions each for old and new depsgraph that are flexible enough to handle all these variations, and uses them to handle particles, cloth, smoke, softbody and dynpaint. One thing to watch out for is that depsgraph code shouldn't rely on any properties that don't cause a graph rebuild when changed. This was violated in the original code that was building force field links, while taking zero field weights into account. This change may cause new dependency cycles in cases where necessary dependencies were missing, but may also remove cycles in situations where unnecessary links were previously created. It's also now possible to solve some cycles by switching to explicit groups, since they are now properly taken into account for dependencies. Differential Revision: https://developer.blender.org/D2141
2016-08-12 18:23:29 +03:00
if (surface->effect & MOD_DPAINT_EFFECT_DO_DRIP) {
DEG_add_forcefield_relations(
ctx->node, ctx->object, surface->effector_weights, true, 0, "Dynamic Paint Field");
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
}
/* Actual code uses custom loop over group/scene
* without layer checks in dynamicPaint_doStep. */
DEG_add_collision_relations(ctx->node,
ctx->object,
surface->brush_group,
eModifierType_DynamicPaint,
is_brush_cb,
"Dynamic Paint Brush");
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
}
}
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
}
Cycles: experimental integration of Alembic procedural in viewport rendering This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache modifier in order to use and test it from Blender. To enable it, one has to switch the render feature set to experimental and activate the Procedural in the modifier. An Alembic Procedural is then created for each CacheFile from Blender set to use the Procedural, and each Blender object having a MeshSequenceCache modifier is added to list of objects of the right procedural. The procedural's parameters derive from the CacheFile's properties which are already exposed in the UI through the modifier, although more Cycles specific options might be added in the future. As there is currently no cache controls and since we load all the data at the beginning of the render session, the procedural is only available during viewport renders at the moment. When an Alembic procedural is rendered, data from the archive are not read on the Blender side. If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural, bounding boxes are used to display the objects in the scene as a signal that the objects are not processed by Blender anymore. This is standard in other DCCs. However this does not reduce the memory usage from Blender as the Alembic data was already loaded either during an import or during a .blend file read. This is mostly a hack to test the Cycles Alembic procedural until we have a better Blender side mechanism for letting renderers load their own geometry, which will be based on import and export settings on Collections (T68933). Ref T79174, D3089 Reviewed By: brecht, sybren Maniphest Tasks: T79174 Differential Revision: https://developer.blender.org/D10197
2021-08-19 14:34:01 +02:00
static bool dependsOnTime(struct Scene *UNUSED(scene),
ModifierData *UNUSED(md),
const int UNUSED(dag_eval_mode))
{
return true;
}
2018-05-12 08:04:56 +02:00
static void foreachIDLink(ModifierData *md, Object *ob, IDWalkFunc walk, void *userData)
{
2012-05-06 13:38:33 +00:00
DynamicPaintModifierData *pmd = (DynamicPaintModifierData *)md;
if (pmd->canvas) {
DynamicPaintSurface *surface = pmd->canvas->surfaces.first;
2012-05-06 13:38:33 +00:00
for (; surface; surface = surface->next) {
walk(userData, ob, (ID **)&surface->brush_group, IDWALK_CB_NOP);
walk(userData, ob, (ID **)&surface->init_texture, IDWALK_CB_USER);
if (surface->effector_weights) {
walk(userData, ob, (ID **)&surface->effector_weights->group, IDWALK_CB_NOP);
}
}
}
}
2018-05-12 08:04:56 +02:00
static void foreachTexLink(ModifierData *UNUSED(md),
Object *UNUSED(ob),
TexWalkFunc UNUSED(walk),
void *UNUSED(userData))
{
// walk(userData, ob, md, ""); /* re-enable when possible */
}
static void panel_draw(const bContext *UNUSED(C), Panel *panel)
{
uiLayout *layout = panel->layout;
PointerRNA *ptr = modifier_panel_get_property_pointers(panel, NULL);
uiItemL(layout, TIP_("Settings are inside the Physics tab"), ICON_NONE);
modifier_panel_end(layout, ptr);
}
static void panelRegister(ARegionType *region_type)
{
modifier_panel_register(region_type, eModifierType_DynamicPaint, panel_draw);
}
ModifierTypeInfo modifierType_DynamicPaint = {
/* name */ "Dynamic Paint",
/* structName */ "DynamicPaintModifierData",
/* structSize */ sizeof(DynamicPaintModifierData),
/* srna */ &RNA_DynamicPaintModifier,
/* type */ eModifierTypeType_Constructive,
2020-01-28 11:42:24 +11:00
/* flags */ eModifierTypeFlag_AcceptsMesh | eModifierTypeFlag_SupportsMapping |
2012-10-24 05:45:54 +00:00
eModifierTypeFlag_UsesPointCache | eModifierTypeFlag_Single |
eModifierTypeFlag_UsesPreview,
/* icon */ ICON_MOD_DYNAMICPAINT,
/* copyData */ copyData,
/* deformVerts */ NULL,
/* deformMatrices */ NULL,
/* deformVertsEM */ NULL,
/* deformMatricesEM */ NULL,
/* modifyMesh */ modifyMesh,
/* modifyHair */ NULL,
/* modifyGeometrySet */ NULL,
/* initData */ initData,
/* requiredDataMask */ requiredDataMask,
/* freeData */ freeData,
/* isDisabled */ NULL,
Depsgraph: New dependency graph integration commit This commit integrates the work done so far on the new dependency graph system, where goal was to replace legacy depsgraph with the new one, supporting loads of neat features like: - More granular dependency relation nature, which solves issues with fake cycles in the dependencies. - Move towards all-animatable, by better integration of drivers into the system. - Lay down some basis for upcoming copy-on-write, overrides and so on. The new system is living side-by-side with the previous one and disabled by default, so nothing will become suddenly broken. The way to enable new depsgraph is to pass `--new-depsgraph` command line argument. It's a bit early to consider the system production-ready, there are some TODOs and issues were discovered during the merge period, they'll be addressed ASAP. But it's important to merge, because it's the only way to attract artists to really start testing this system. There are number of assorted documents related on the design of the new system: * http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents * http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph There are also some user-related information online: * http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/ * http://code.blender.org/2015/03/more-dependency-graph-tricks/ Kudos to everyone who was involved into the project: - Joshua "Aligorith" Leung -- design specification, initial code - Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes - Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the project and so - Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the issues and recording/writing documentation. - Everyone else who i forgot to mention here :)
2015-05-12 15:05:57 +05:00
/* updateDepsgraph */ updateDepsgraph,
/* dependsOnTime */ dependsOnTime,
/* dependsOnNormals */ NULL,
/* foreachIDLink */ foreachIDLink,
/* foreachTexLink */ foreachTexLink,
/* freeRuntimeData */ freeRuntimeData,
/* panelRegister */ panelRegister,
/* blendWrite */ NULL,
/* blendRead */ NULL,
};