alembic has a python api, so that mean's you can rapidly develop and re implemented if you choose. and a pretty extensive camera class. http://docs.alembic.io/python/ http://docs.alembic.io/python/alembic/abcg.html#alembic.AbcGeom.CameraSample
are you sure the camera isn't extensible? all alembic object's can be extended with arbitrary user data... http://docs.alembic.io/python/examples.html#write-non-standard-data-for-a-polymesh agreed, the only headache is the compilation. but again... we should push the maintainers to provide binaries to make this easier. i am sure if pyqt didn't come pre packaged binaries the pyqtforsoftimage plugin would be used a lot less. so let's encourage them to do so. lastly, i think the file size isn't a big issue... at least not for a camera only. yes, alembic does compression but their other features which make it great (data deduplication) is probably not going to apply to a camera. just so you guys know, i am not against the idea. by all means make the tool and make it awesome! i personally like to stop and ask, 'do i really need to reinvent the wheel?' it is very easy to jump to this conclusion, but you need to ask yourself that question or avoid repeating the mistakes. and when it comes to interop formats this has been going on forever and is usually the reason a project like alembic started in the first place. On Wed, Jul 10, 2013 at 12:43 PM, Alok Gandhi <[email protected]>wrote: > The only downside I might see with Alembic Camera is the inability to > customize and extend according to one's need. To suite the various needs of > the productions which might change with each show/project having full > development control over simple python classes is way more rapidly > developed. Also the reader and writer plugins for various DCC apps can be > very easily implemented and incorporated in the existing pipeline using > python. And then there is the question of cross-platform development which > is a breeze using python. > > Not that I have anything against the Alembic Camera, of course it is > awesome but might involve a lot of headache with having to compile the > whole libraries especially on windows just for the cause of a camera IO and > this might be a daunting task for TDs/Devs who do not have much experience > with compiling C++ code on various platforms. > > I would recommend (as suggested before in this thread) to have base class > as the data container (basically a python dict) and then to derive from > that class a class for each DCC, then use this derived class in the > reader/writer plugins. > > In fact as a bonus you could use the same classes for export/import of > light data between various DCC. > > The only optimization to look for is for the same values at different > frames and to implement some sort of compression to make the file size > smaller. RLE is one compression that can be implemented but there are other > awesome easy to implement in python (In fact alembic does this brilliantly > and it is one of the strongest USP for it). > > Finally, if the writer plugins are not going to use fcurve (bezier) > plotting then you need to do more work in the plugins for the interpolation > (which according to my view is also fairly easily implemented using various > universally accepted methods like bezier, hermite for position and scaling > and slerp/nlerp for rotations). > > >
