meta SDK sharing concept, utilizing Maya ASCII format + USD

[Nolan]

\\\\\
As stated previously:

On 21 Apr 2012 here: http://www.si-community.com/communi...?p=18544#p18544

When the Softimage developers were reorganized, I wrote:
“What Autodesk should have done with Maya & Softimage:

Softimage has most of what Maya users want except in the SDK and SDK compatibility. So Autodesk should have created a Softimage meta SDK underneath SDK's for Maya and perhaps Max so that those teams could implement their SDK’s on top of it. This way studios get to keep all their custom development and Softimage gets an even better SDK. They get one app with the very latest in modern SDK's, without a complete rewrite. Convert the Softimage GUI to QT and modernise the OS calls so it runs across all main OS platforms. To make the largest crowd happy, change the look and call the app Maya and see how happy they are with: New modern modeling workflow, symmetry, ICE, mental ray integration, rendering workflow, less workarounds, overrides, supra keys, multiple attribute editors open at once, etc
”

Sometime later we got Fabric Engine Splice and Houdini Engine. Apparently when a meta SDK comes from a third party its called an Engine. From Autodesk maybe its called Bifrost. I'm not familiar with that acquisition.
////

You could get a lot of the sharing functionality of this meta SDK by implementing an ASCII file format that could share a lot of the same format as Maya ASCII perhaps with comments with encoded data where features were missing from Maya. Plus you would get great interop.

All though you can never conceive of the all the mapping limitations and corner cases in advance. But with a bit of text processing a lot would be possible.

If I understand it correctly, with Pixar USD ( Universal Scene Description ) in the works and Alembic new on the scene maybe Autodesk would update the Maya ASCII format in design concert with Max and Softimage a la the graph editor standardization.

If not how about an ASCII format for Softimage combining USD and elements from Maya ASCII with comment embedded encoding?

Pixar USD ( Universal Scene Description )
http://graphics.pixar.com/usd/
Pixar USD videos-
http://vimeo.com/user14728591/videos

If you need ASCII or better Maya interop - Vote for it here:-
http://softimage.uservoice.com/forums/225405-unofficial-idea-for-autodesk-softimage/category/72458-import-export

[luceric]

It's funny how you quote yourself from past posts ;)

USD is not actually a universal scene file format "in that way". It's a scene assembly format, which mean it's used to describe how to put final assets together for a shot or a "scene" as they call it at Pixar. Baked assets, caches. It has nothing about construction history or other things you need to correctly load and save an XSI or Maya scene, or even animation you can edit. It's basically like a RIB/MI2 file referencing archives, alembic and .objs.

This whole "meta SDK" doesn't make much sense to me. There is a 3D architecture in each application, and the SDKs and scene format are part of it. There are objects, kinematics architecture, plus operator stacks, plus property and their propagation, etc in XSI, and on the Maya side there is the DG, the DAG, transform nodes, etc. They are irreconcilable, stuff simply isn't structured the same at all. There is almost zero commonality in concepts. The point of an SDK is to integrate your code with what's specific to an application's architecture. If the API were the same, then it would mean the application architecture is pretty much the same. It means there is really just one application. The products only exist as thin UIs on top their architecture.

[Nolan]

USD is not actually a universal scene file format "in that way". It's a scene assembly format, which mean it's used to describe how to put final assets together for a shot or a "scene" as they call it at Pixar.

I have designed and implemented the second pass of something similar which does covers some of this USD functionality but which I hope to be a used in a file format.

For an example of the crowd funding idea. If I was getting a lot of work because of Softimage with the above implemented pipeline, I would consider contributing as much as $10,000 toward crowd funding an ASCII effort. But I suppose I could through normal crowd funding and Autodesk consulting. It would be nice if it was legitimized through Autodesk setting up something like http://crowdfundingsite.net/ so it could be co-ordinated with other interested parties and be certain the trigger was being pulled with no negotiation shenanigan's and the costs were driven down by involving at least ex employees.

You couldn't parse Maya ASCII rigging nodes, bones in particular, maybe IK, in subsequent versions perhaps attached primitives maybe requiring a redesign rigging system in Softimage, which a lot of people would appreciate, and map across the ASCII somehow? And then when saving XSI specific features, add comment embedded encoding?

Maybe this exists as advertising to those who would be interested enough to pay Autodesk consulting for it.

I suppose if you don't have the resources to do a whole ASCII format then this would be just another import/export format. And since my interest is in an ASCII format and my knowledge limited on their current capabilities maybe the current ones are good enough.

So maybe rigging and primitives?

This whole "meta SDK" doesn't make much sense to me. There is a 3D architecture in each application, and the SDKs and scene format are part of it. There are objects, kinematics architecture, plus operator stacks, plus property and their propagation, etc in XSI, and on the Maya side there is the DG, the DAG, transform nodes, etc. They are irreconcilable, stuff simply isn't structured the same at all. There is almost zero commonality in concepts. The point of an SDK is to integrate your code with what's specific to an application's architecture. If the API were the same, then it would mean the application architecture is pretty much the same. It means there is really just one application. The products only exist as thin UIs on top their architecture.

Autodesk maybe didn't interpret or weren't in a position to move but Fabric Engine and Houdini Engine started delivering and announcing products respectively a year later.

Great work on Softimage by the way!

[luceric]

Autodesk maybe didn't interpret or weren't in a position to move but Fabric Engine and Houdini Engine started delivering and announcing products respectively a year later.

Maya delivered its equivalent of the Houdini Engine in 1998, just fyi. you can load the maya engine in any other app using the MLibrary API class (or in python). It doesn't even take a license. the Houdini engine is a catch-up to Maya. I'm not aware of anyone loading the "maya engine" in softimage to implement some feature, of course. If features in softimage are not implemented natively, the advantage of using softimage is diminishing, that was my earlier point.