Saving Custom Data in .duf
Kendall Sears
Posts: 2,995
I have a situation where I need to save custom data into the .duf file with the scene. I can get an object to save, but I cannot seem to get any of the callbacks to execute to allow me to put my data into the "extra" sections. Are there any examples on saving data that are completely foreign to DS, but are critical for the plugin, to save in the scene's .duf?
EDIT: What would be more useful is a flow diagram on what is happening on .duf save/load and when/why, in the process, specific routines are called.
Also, what caveats should I watch for when (if) I can save the data, for reading it back out?
Kendall
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Do these threads help:
http://www.daz3d.com/forums/discussion/10728/
http://www.daz3d.com/forums/discussion/11040/
Same problem for me. Some more examples, or detailed documentation would be very helpful.
lets call where you install the SDK to be SdkFolder, the following examples exists
- SdkFolder\samples\saving\customsceneelements
- SdkFolder\samples\saving\customscenedata
- SdkFolder\modifiers\DzBlackHole
customsceneelements shows the following custom elements
- custom DzNode
- custom DzModifier
- custom DzMaterial
- custom DzShape/DzGeometry combination
customscenedata shows a custom DzSceneData
DzBlackHole is a world space modifier(very esoteric, but it does show how the extra information radius is added to the Custom node. Because the DzProperty is known to the system, it does not need custom save work. In fact, all it needs is on read, the proper stuff to be created. Note: createNode() and applyInstancetoObject
------------------------------------------------------------------------
I am assuming that you want a custom DzSceneData?
In any case, from a high level point of view, the write works something like this.
- gather all the scene assets in the scene that Studio can find(think IDzSceneAsset). A custom DzNode will be found if it is added to the scene via dzScene->addNode. If its not added to the scene, Studio does not know about it.
- assign ids and stuff to the assets. In DSON, there are no pointers, so the issue of resolving assets becomes quite a bit of work and complexity.
- write out definitions
- write out instances
- write out animations
------------------------------------------------------------------------
Kendall,
Do the samples not work for you? Can you come up with a scenario that you would like a sample of?
lets call where you install the SDK to be SdkFolder, the following examples exists
- SdkFolder\samples\saving\customsceneelements
- SdkFolder\samples\saving\customscenedata
- SdkFolder\modifiers\DzBlackHole
customsceneelements shows the following custom elements
- custom DzNode
- custom DzModifier
- custom DzMaterial
- custom DzShape/DzGeometry combination
customscenedata shows a custom DzSceneData
DzBlackHole is a world space modifier(very esoteric, but it does show how the extra information radius is added to the Custom node. Because the DzProperty is known to the system, it does not need custom save work. In fact, all it needs is on read, the proper stuff to be created. Note: createNode() and applyInstancetoObject
------------------------------------------------------------------------
I am assuming that you want a custom DzSceneData?
In any case, from a high level point of view, the write works something like this.
- gather all the scene assets in the scene that Studio can find(think IDzSceneAsset). A custom DzNode will be found if it is added to the scene via dzScene->addNode. If its not added to the scene, Studio does not know about it.
- assign ids and stuff to the assets. In DSON, there are no pointers, so the issue of resolving assets becomes quite a bit of work and complexity.
- write out definitions
- write out instances
- write out animations
------------------------------------------------------------------------
Kendall,
Do the samples not work for you? Can you come up with a scenario that you would like a sample of?
The samples work fine, as far as they go. What I want to do is more complex than what is described within the samples. For the current project, I need to attach lots of custom definition information to nodes. In some upcoming projects it gets more complex, dealing with encryption, CMS issues and the like.
Kendall
Your choices for serialization of data are something along the following:
- primitives.
- array of primitives
- structure of primitives
- structure of arrays of primitives
- arrays of structures or primitives.
- structures of structures
On the write, primitives are shown, array of array of primitives is shown. Do you want the array of structures case shown? or a structure of structures? Or am I misunderstanding completely.
Things get really complicated when we have a graph, where it is not obvious who is responsible to save out structureA, like the following situation.
Node1
- Pointer to structureA
Node2
- Pointer to structureA
Your choices for serialization of data are something along the following:
- primitives.
- array of primitives
- structure of primitives
- structure of arrays of primitives
- arrays of structures or primitives.
- structures of structures
On the write, primitives are trivial, array of array of primitives is shown. Do you want the array of structures case shown? or a structure of structures? Or am I misunderstanding completely.
Things get really complicated when we have a graph, where it is not obvious who is responsible to save out structureA, like the following situation.
Node1
- Pointer to structureA
Node2
- Pointer to structureA
I'm reevaluating my options based on your response. How about the ability to add an appendix section to the .duf containing abstract data that may contain anything? This section would be fed raw to the plugin to do whatever is necessary.
Kendall
By raw, do you mean binary? Either way. Raw to me means that you don't really want or care for it to be human readable. In that case, I would get yourself a QByteArray of your data and call toBase64() on it. then write it out as a string.
If you have pointers to DzNode's and other daz object, then would of course have to account for that and devise a way to resolve those pointers.
By raw, do you mean binary? Either way. Raw to me means that you don't really want or care for it to be human readable. In that case, I would get yourself a QByteArray of your data and call toBase64() on it. then write it out as a string.
No, by 'raw' I meant that DS/Carrara doesn't try to do *anything* with the section other than pass it along. It's possible to assign a null and then do as you suggest with a QByteArray, I just was hoping for something a bit more 'formal.' Something like: "Here's a section of the .duf that belongs only to the plugins." You know, somewhere where we can store custom scripting code, unforseen datatypes, etc without involving DAZ or breaking the .duf file.
"appendix" : [
{
"id" : "My Plugin's Demented ID",
"name" : "My Plugin's Demented Name",
"type" : "abstract",
"label" : "Nanny Nanny Boo Boo",
"Demented Field value name1" : "value",
...
}
]
Kendall
I am not sure what you mean by assign a null, do you mean create a custom DzNode that does not do anything besides hold data?
From my point of view, a custom scenedata is an appendix for your plugin. Is that not what you want?
I need to reevaluate some issues before I say too much more. I believe that you've provided me with what I need to work out the current project's issue.
Some of the things I'm looking to try to do would cause quite a firestorm if discussed in an open forum.
Kendall