Vasily Levin - 01 December 2012 02:26 PM
Could resolve most problems, have several problems to solve though.
1. how should I implement save/load for objects derived from DzBase? in my case they are owned by another object of DzNode type. I would like their load to follow same architecture but do not see how to make DS loader to initiate writing/reading of those object. Maybe I should base them on other class? I first thought about DzSceneData, but examples has bogus comment about it that DzSceneData of a given type is singleton and can have only one exemplar. And also it is not clear if old scenes would load if I base class on the other type.
Let’s assume you have VasilyThing : public DzBase and VasilyNode : public DzNode ?
- am I correct in my assumption?
If your VasilyThing wants to be saved you can do one of the following,
1) VasilyNode needs to write out the data of VasilyThing
2) or you need your VasilyThing thing to implement IDzSceneAsset. See MyCustomModifier.h
In the case of #2, VasilyNode will still need to tell the system to save VasilyThing using getOwnedAssets.
void MyCustomNodeIO::getOwnedAssets(QObject* object, QList< IDzSceneAsset* >& assets)
{
MyCustomNode* node = qobject_cast<MyCustomNode*>(object);
// we don't need to do this since we added our property to the node.
// this is shown as an example for when you have assets that are not known to the system.
//assets.push_back(node->m_property);
}
2. What is the difference between instance write/read and defenition write/read? when they are called and what supposed to be loaded on each state?
definition, think library
instance, think actual thing. an instance can reference a definition(does not need to be in the same file) and apply extra settings. An instance cannot be referenced outside the file it exists in.
I would suggest to read the spec while looking at some duf and dsf files.
- http://docs.daz3d.com/doku.php/public/dson_spec/start
3. How can I prevent DS from saving some data? I have a nodes with auto-generated geometry and does not want to keep it in file I am getting compressed save file of size 10MB and about 200MB uncompressed, but actually it would be enough several kilobytes to store my data.
if you create a generic DzFacetMesh and put it on a DzNode, it ‘s going to save with the scene.
I know for sure you can do it if you implement your own Shape/Mesh. You may be able to do it by subclassing DzFacetMesh and overriding some of IDzSceneAsset, I will look into that.
Or you could watch for the following signals on dzScene and remove your geometry when the save happens:
void sceneSaveStarting( const QString &filename; );
void sceneSaved( const QString &filename; );
and 4. is just a complain, please make a documentation for your new serialization system at least comments to parameters and return values in the declarations, that already would be a huge help. also architecture overview with description of stages and on what steps what object are created and initialized. without that data implementing serialization to the new format is very discouraging process.
The current save and load paradigm is at least a 10 fold increase in complexity. The old .DAZ paradigm was great for the programmer and very orthogonal, but for the user it had severe limitations.
Again, the best place to understand it is to read the spec while looking at some duf and dsf files.
- http://docs.daz3d.com/doku.php/public/dson_spec/start
hopefully we will figure out a better way to convey the architecture and best practices.
