Hmm.. I don't really understand - you say format doesn't matter and that it may cost different export times at once. I meant that total export time is the difference.
As hard drive space is of no concern there's no need for packing or processing data at all. Ideally data order "key" is everything needs to be saved besides mesh and this could mean - as fast as hard drive bus handles. And, ability to import raw data directly into octane would mean same fast import too.
Ok, have tested it with a sphere that have 1mio tris.
original obj-export uses in Softimage 50sec, 119MB
original lwo-export uses 20sec, 16.5MB
original fbx-export uses 30sec, 22.3MB
original collada-export uses 5sec, 64.7MB
Mine uses 10sec, 119MB
obj is textbased, the others are binaries.
I think collada is unpacked, the other binaries are packed.
I don´t know how deep the exporters are integrated into Softimage and which type of meshes are exported.
With type i mean instances, clones, models, particles or strands.
At last, Collada is the speed winner and can also export camera/light data.
Mine should be the feature winner and can also export baked textures.
This is only for Softimage, on an other app, it can be different.
The result is, we should use an format which can handle the most things we need.
Binary would be fine, it´s the fastest. The problem would be, who should integrate it into our 3D-App.
I think that there are only 2-3 plugins written in c++, the rest are scripts that uses the buildin exporters.
Later it might be done though clipboard on some OS or other more civilized way eliminating the need for restarting Octane.. oops - back to reality
Camera animation can work with a little trick like this, but I think, I will it never make public
http://www.vimeo.com/22785409
Should be true. Then why are those so slow compared to exporting binary formats, like app native ones? May it be they're just not meant to take load of more than occasional use, so no one cared enough to do the conversion using the trick you are talking about? Btw I often need to convert large amount of data to text and back. Is that trick a common knowledge
I think thats the point, you can use it to convert occasional a mesh. It is infrequently used to export a 1000 frame animation.
Should be true. Then why are those so slow compared to exporting binary formats, like app native ones? May it be they're just not meant to take load of more than occasional use, so no one cared enough to do the conversion using the trick you are talking about? Btw I often need to convert large amount of data to text and back. Is that trick a common knowledge?
Maybe the native ones have direct access to the meshdata and can write it 1:1 in a file, without the way to get a structure of the exported mesh.
Another option is, that the native format uses assembler for time critical code.
The Softimage native format uses 1sec for the 1mio tri sphere...
The trick i use is not a trick, i use the BString library which are a replacement of the std::string class.
You can found it here:
http://bstring.sourceforge.net/
And an description here:
http://bstring.cvs.sourceforge.net/view ... threv=HEAD
face
