Collada Support in Snow Leopard?

Moderator
Posts: 3,577
Joined: 2003.06
Post: #1
I just noticed on one of the new pages describing Snow Leopard features, a little nugget which says there will be "system wide" support for Collada. You can find the page here -- just search for collada on the page.

I haven't been able to come up with any more information about it than that. I don't have a select membership, and thus no access to the developer seed of SL, and I realize it is covered under NDA, but... Is there anybody who might be able to offer a little more hint as to what "system wide" support for Collada might mean? Is there going to be an import/export API, or is it just for Preview (and quick look in the Finder)? Why would it be under "system wide" if it was just for Preview, maybe just because there's quick look support?

I am not trying to encourage anyone to violate NDA, but I have recently been developing with FBX for model support and it could save me a significant amount of labor (perhaps worth the cash to sign up for select membership) to know if I should just forget about FBX and wait for Snow Leopard. I had figured that FBX was going to be "the standard", but this news may suggest that I called it wrong and Collada is a better bet instead.

BTW, I realize there is some Collada support in FBX, but I've heard it is terrible at best, so I haven't bothered with it.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #2
AnotherJake Wrote:I just noticed on one of the new pages describing Snow Leopard features, a little nugget which says there will be "system wide" support for Collada. You can find the page here -- just search for collada on the page.

That doesn't make any sense at all. There must be some other tech called "Collada", because, well, what good does collada support provide outside of games?

EDIT: I just read the page. It is what it says it is. How odd. I assume it's there solely so people in game dev pipelines can quicklook and otherwise view assets.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #3
Odd indeed...

The picture I am imagining is that Apple may somehow be expecting Collada will be "the standard" way of interchanging 3D data between 3D apps, such as Maya, Blender, Cinema4D, etc., much like .obj has been for static models for so many years now. That is certainly not strictly in the realm of 3D game developers, since myriad 3D artists use those programs as well. But if that's the case, then why didn't they provide a viewer for .obj?

One other point to take note of is that Apple has been [apparently] heavily involved in the khronos group, which apparently has ownership of Collada. Is Apple up to something? More gaming technologies perhaps? Does this tie into iPhone somehow?

I don't really care right now about what may be going on behind the scenes; I just wanna know if I'm wasting my time pursuing FBX support for my future apps.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #4
Well, I wouldn't put too much stock in it. Any game or 3d app is going to have its own collada parser. It's not like EA (for example) is going to use their own parser on Windows, but link against Apple's for OSX deployment. And it's not like Apple gives a huge hoot about us indie types.

I strongly lean towards it being a nice touch for people in the game & 3d asset pipeline world. Solely for creating icons in the finder, quicklook, etc.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #5
I guess i can confirm that Collada files are indeed opened by Preview. And I'd like to know how they do it, too, as it's a heck of a lot faster than my own Cocoa Collada parser.

Not sure how much there is to it API wise, though.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #6
My interest in Collada just went from about 20% to about 90%.

@TomorrowPlusX: I suspect you're probably going to be right about them not sharing any API for it, but I guess we'll have to wait and see.

Here's where my stock is in it: FBX has some drawbacks to it, like it is a rather large library to have to package up with any game/app and Autodesk specifically recommends against writing your own parser for it, and the library is quite a PITA to work with. Although, I am specifically working on extracting geometry and skeletal animation info from the loaded model to convert it to my own format for size/convenience... But if Collada winds up being "the standard", I don't see much purpose in further pursuing FBX support. And I happen to be right at a point where I don't have my FBX support far enough along to have lost much labor if I stop now. Plus, my end-users for an app I have in the pipeline would likely appreciate a model format that is quick-lookable.

DoG, I am curious, why did you have to write your own Collada loader? Isn't there a decent third-party loader out there somewhere?
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #7
One reason not to use FBX is that it's a) a really really horrible API and b) C++.

Just doesn't fit in with Cocoa. So, I wrote an ObjC Collada loader for my udg project, and in the meantime it's become pretty complete for static scenes.

So, Collada is not supposed to be a "final" format, so its kinda complex and redundant, and I believe similarly crappy as FBX, but at least it's a documented file format.

Anyhow, what I do is load the XML via Cocoa, create an intermediate Collada scenegraph, then transform that to my engine's scenegraph which I use in the game. It does a couple interesting things on the way, like preparing data for VBOs and generating normals if necessary. Some version of the code is in my udg submission, but I have better code now, which i'd be happy to share if you need it.

And I forget what else I was going to say.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #8
I appreciate the offer, and I might be bugging you about it at some point. Smile

Now I feel like I'm going to have to research this Collada direction more before I resume FBX development. I have other stuff I'm working on for the time being, so I guess I have time to "wait and see" what pans out with Snow Leopard.

The fact that the FBX API is C++ isn't anywhere near as bad as the fact that it is really bad C++, and represents pretty-much everything there is to dislike about C++, as far as I'm concerned. I can work with their nutty C++, but the lack of remotely decent documentation, combined with buggy demos, are what has slowed me down with it.

The point you make about Collada at least being a documented *file format* (as opposed to only an SDK) is quite persuasive. What's not so cool is that I don't see as much Collada support in 3D editors yet. I posted a question regarding Cheetah3D support at Martin's forum this morning but haven't heard anything back yet.

I don't know what 3D editors on Mac support Collada, although I seem to recall Blender does.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #9
Can anybody describe collada succintly? Yes, I have googled, but what I find is mostly corporate fooferah. I assume it's more than yet-another-model-format. It must bring a lot to the table...
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #10
Interesting, looking at the modelers I have and it appears none of them export to Collada ( .dae ) -- Carrara Pro 6.2.1, Silo 2.1.1, Cheetah3D 4.6.4 and Modo 302. I was avoiding fbx because it just seemed to blow up in all these programs -- but fbx seemed to be popular with the Cheetah3D users and unity.

Though, I like to import everything into sqllite files now. Use blobs etc. There is a nice simple app called Base for browsing the sqllite files ... found it on Apple downloads. Maybe even try to set the tables up to play better with core data. I guess the only issue is the endian thing. But the iphone does not have an endian issue with intel macs and snow leopard is not supporting ppc anymore...

Looks like Collada is Khronos group thing. Think they are sharing the rights to the format...

"COLLADA 1.4 supports all the features required for game development for all platforms, including Mac, Windows, Linux, PLAYSTATION 3, Xbox 360, Wii.

This includes geometry, materials, textures, lights, camera, animations, instantiations, and scenes. COLLADA also includes skinning and morphing for character animation. Shader effects for several shader languages are included (Cg, GLSL, OpenGL ES 1.1, and a standardized platform independent simple model and via common convention extensions support for binding to HLSL based FX and CgFX) as well as all the physics properties for rigid bodies, and the associated analytical shapes, and constrained joint systems."
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #11
macnib Wrote:Interesting, looking at the modelers I have and it appears none of them export to Collada ( .dae ) -- Carrara Pro 6.2.1, Silo 2.1.1, Cheetah3D 4.6.4 and Modo 302. I was avoiding fbx because it just seemed to blow up in all these programs -- but fbx seemed to be popular with the Cheetah3D users and unity.

That has been my observation as well, so I'm wondering where Apple's notion of Collada being "a popular way to share 3D models and scenes between applications" comes from? FBX works for me, from Cheetah3D and Maya.

3D editors don't have a single format in common amongst them. It is an issue that frustrates 3D artists more than game developers. Here's my issue: I can write an exporter to my own format from several different editors, but in practice I only want to write an exporter from one. I did that from Maya, both from Maya API and from MEL. Then they changed companies *and* the preferred scripting language from MEL to Python, and jacked up their price again, and so I was basically forced to ditch Maya -- along with my exporter(s). So after that experience, I realized it would be ideal if there were simply a file format that was common among editors that I could either import into my engine or convert, rather than a custom exporter from just one 3D editor. FBX looks like that solution right now.

FBX has a critical flaw though: it is a non-open file format. That creates an issue where we're basically forced to either convert the model formats with a separate converter of our own, or build with the SDK included statically in our products, at the cost of like 12 MB of bloat (non-stripped), plus an ugly API. OR, take a chance that the file format won't change and extract it directly from there, although that is a somewhat risky proposition in my view, since there is nothing stopping Autodesk from changing it dramatically at-will.

Collada appears better in theory, but I don't see a loader library for it -- yet --, and I don't see much 3D editor support for it -- yet. I could get past the loader myself, but I am skeptical many 3D editors will bother. If Apple provides an API, at least on the Mac, then I would feel 100% confident that the Mac builds of popular 3D editors would adopt Collada. Otherwise, I don't see how momentum will build for it any time soon, and offering quick-look and preview for it alone will not do the trick -- that is unless there is something else going on in the industry back-rooms that we don't know about, but I doubt it.

[Edit] ... I guess what I'm saying is that if Apple (or somebody else) doesn't provide a solid, industry-wide, API for Collada, then Preview/Quick-look for it alone won't change a thing.
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #12
Quote:FBX has a critical flaw though: it is a non-open file format.

That is the problem with fbx in a nutshell. If there is some kind of problem, then I'm not sure how to quickly fix it. Also, I was reading on the Cheetah board that newer versions of fbx solve problems but then they cause the older versions to crash when they read the file.

I just like a database file approach. Then people just need to create queries which is much simpler. The person creating the modeling program can name the tables whatever they want. Don't really have to construct a complicated parser. But I suppose streaming in xml solves some of that problem. Cocoa has NSXML ....

Though, I like that Collada has support for shaders. I'd have to read up more on the standard but I wonder how it would map its texture units etc. Still, if Collada and obj are choices for me I'd be happy.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #13
The thing with Collada is that it has provisions for custom data, which importers can choose to ignore freely. So Collada is a good format in that sense, but this also incurs some complexity.

So, it does theoretically allow you to all kinds of project-specific stuff without having to resort to a custom file format to go from one editor to another. The intent is that you can, for example, create a plugin in your favourite editor to annotate 3d models with physics information, and then load that into some other tool in your toolchain to postprocess, but you can open the same file in some other editor that doesn't know about the physics info, as well. Or, alternatively, a Collada doc can contain all kinds of editor-specific data, which isn't used in your game, but you can just leave it in there, use it with all your tools, and then just strip it before you ship the game.

Cinema 4D exports Collada, and converter tools are available to convert between Collada and FBX.

Personally, I find the API approach to FBX very counterproductive. You get to load a scenegraph which 99.9% of the time you have to convert to your own scenegraph anyway, or have to do significant work to integrate it. To draw your models, you have to do everything yourself anyway.

There's other attempts that are just as bad, such as OpenSceneGraph, which at least also includes the rendering stage, but the basic design just doesn't match modern hardware anymore.

So, due to the diversity of optional data a Collada (or any interchange file format) doc can contain, there's no real point in an API, though some code to build on would be nice.
Quote this message in a reply
Nibbie
Posts: 1
Joined: 2009.06
Post: #14
Since Apple is a member of Khronos, Apple can gain early access to the COLLADA Conformance Test Suite in development. That would be very important for Snow Leopard to pass and show that Apple is providing a conforming implementation of the COLLADA specification to Mac OSX users world wide.
Quote this message in a reply
Moderator
Posts: 3,577
Joined: 2003.06
Post: #15
collada Wrote:Since Apple is a member of Khronos, Apple can gain early access to the COLLADA Conformance Test Suite in development. That would be very important for Snow Leopard to pass and show that Apple is providing a conforming implementation of the COLLADA specification to Mac OSX users world wide.

This is interesting, because it seems you're suggesting, in a round about way I suppose, that Apple would indeed be working on providing some sort of API. Otherwise, who cares if they provide a "conforming implementation" if it is only just for Preview/Quick-look?

Sigh, the burning question remains... API or no API?

DoG, I like that you can use your own custom data in Collada without it interfering.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Trouble using SDL_image with XCode 3.2.3 Snow Leopard code4fun 1 4,396 Sep 22, 2010 10:47 PM
Last Post: OneSadCookie
  Snow Leopard and OpenCL TythosEternal 4 4,313 Jun 12, 2009 08:05 AM
Last Post: AnotherJake
  Objective-C Collada Importer DoG 3 6,750 Feb 27, 2009 01:35 AM
Last Post: skumancer