|
3dNewb, Sr. Member
Posted: 29 June 2012 11:23 AM Total Posts: 105
Easy as that. Object is created by the user and I’d like to save it for later use within Flash.
What is the fastest way to store an Objectcontainer3d with all (or most) of its properties to disk?
I don’t think using a .3ds or .obj format is efficient. I’m looking for speed.
I was considering AMF, but maybe you guys can point me in a better direction ?
|
theMightyAtom, Sr. Member
Posted: 29 June 2012 01:25 PM Total Posts: 669
[ # 1 ]
That would all depend…
Do you want to then use the object in another application?
Are we talking, save in cache, save for next session on same machine, save to database?
AWD2 would be the obvious choice as it’s a binary that reflects all the possible features of Away3d (and is likely to incorporate any new ones they think of). There must be a class for writing AWD2 in Prefab2. I haven’t seen one in the wild. Fabrice?
Good Luck!
|
3dNewb, Sr. Member
Posted: 29 June 2012 01:59 PM Total Posts: 105
[ # 2 ]
The model should be saved to disk so that I can import it at a later time. After the application is closed.
I’ve seen the AW2 file format in the api docs, but no exporter to this file format.
If I think about what is required to build a objectcontainer3d, I come to:
For every mesh in the object:
- vertex data (Geometry)
- normal data
- material reference ( I can get away with just a material name in my case actually)
- position
- rotation
- scale
I’ll try to go and save these as an AMF objects or ByteArray’s and see where it gets me
|
Shegl, Sr. Member
Posted: 29 June 2012 07:10 PM Total Posts: 134
[ # 3 ]
Plz report if you will had success.
|
Richard Olsson, Administrator
Posted: 30 June 2012 09:31 AM Total Posts: 1192
[ # 4 ]
If I were you I would just create a custom data format for this. If file size is important (and meshes are likely to be very high-poly) you should go with a simple binary format, but that will likely be harder to do if you don’t have experience designing file formats, or dealing with binary data in some other way. If size is not hugely important, just create an XML-based format.
To then load the files, just parse the data as you do with any other file you use in your Flash projects (e.g. XML configuration files.) If you have custom stuff (like the material names instead of material definitions) I see no reason to use the loading architecture at all. Especially since all you need is such a very simple data format.
|
|