Collada Support in Snow Leopard?

Moderator
Posts: 3,570
Joined: 2003.06
Post: #16
As a little update: Martin replied that Cheetah3D 5 will start out with Collada static mesh and material export and he plans to expand that to full Collada support later. I don't know when C3D 5 will be out though. That's at least somewhat encouraging news on that front, although I'd be more excited if skeletal was included right away.
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.06
Post: #17
Long thread, lots of questions. I hope I can bring some answers

Quote:Can anybody describe collada succintly?

COLLADA defines an XML-based schema to make it easy to transport 3D assets between applications - enabling diverse 3D authoring and content processing tools be combined into a production pipeline. The intermediate language provides comprehensive encoding of visual scenes including: geometry, shaders and effects, physics, animation, kinematics, and even multiple version representations of the same asset.

It is a standard under the Khronos organization where the specification and schema can be found.

A reference book explains why/how it was created, and goes into details of the 1.4.1 specification.

There are 2 existing versions: 1.4.1 which is the most currently used specification, covering all the needs for game development. 1.5 which adds better support for shaders and features such as IK (inverse kinematics) and BREP (boundary representations). collada.org is the main place for the community with wiki, forum...

Quote: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.
Yes, FBX has minimal support for COLLADA, which last I looked at is not conforming to the spec. So best is to download the open-source plug-ins
The next-gen plug-ins are based on new direct-write export and SAX parser import that is faster and more important use very little memory. All other export/import I know of (FBX, previous gen COLLADA,..) suffer from the fact they copy 2 or 3 times the data in memory before saving to disk. If the data is big (barely fits in the tool), this means your computer will be swapping memory for 20 minutes before crashing. The next-gen exporters work really with any size data, and especially well with very large data.

Quote:Is there going to be an import/export API
4th generation languages do not need a specific library/API to load a COLLADA file. I am not very familiar with Objective C, but I understand there is a technology 'PLIST XML' that can very easily parse and load a XML file and provide it directly in memory for parsing. That's one of the reason COLLADA was built on top of XML, so all the effort/tools/libraries used to load XML can be applied to 3D.

The reference API for COLLADA in C++ is the COLLADA DOM. The COLLADA DOM is semi-automatically created from the COLLADA schema. Tools like FXComposer (although mostly written in C#) are using the COLLADA DOM to load/save.

Another library is FCOLLADA, which provide a slightly higher level of abstraction, so easier to use, but does not provide access to all the core elements so may not be the first choice if you intent to add your own data. (note the link is for the source code, which contains Xcode project files)

Quote:what good does collada support provide outside of games?
COLLADA original goal and specification was to provide a standard format for game developer to find all the data they need in a standard language, as well as providing a content pipeline that enable extensions, and many specialized tools to be working together... as opposed for developers to have to create their own exporters, understand how the SDK of each DCC is built, go around bugs...

Quickly it became clear that the problem COLLADA was solving was not limited to the game industry. The need for a common language between tools,or/and the need to bring data to run-time applications pushed COLLADA in other applications outside of gaming such as Google Earth, Sketchup , Bentley, Autocad, Catia, Poser, Daz. Photoshop CS3 extended introduced importing COLLADA 3D into 2D images, and CS4 now offer 3D painting and export of COLLADA. Avid can now import COLLADA into video composer. ABB and other robot manufacturers can use COLLADA to create and animate virtual robots in virtual factories. Virtual worlds are slowly converging to COLLADA for exchange of data MediaGrid, Sirikata, Sun-Wonderland. Model repositories such as 3DWarehouse, 3Dvia are growing with COLLADA models. 3D for the web is growing rapidly with COLLADA support papervision3D/Flash, Google O3D..

Quote:Collada is not supposed to be a "final" format
COLLADA is a language more than a format. The MPEG group has already standardized COLLADA as a 3D language embedded into a MPEG4 stream, with specific methods of compressions for geometry/textures/vertex data. COLLADA works really well as a XML encoded language between and application and a database. The question of "final format" is more an question of packaging. Are files the right way to package data nowadays, I am not sure that is the case since most of the time data needs to be streamed. So regardless of the final packaging chosen, COLLADA can be used to store the information needed.

Quote: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.
Carrara 7 has COLLADA

Modo 401 has COLLADA

It is more and more difficult to find a package that does not have support for COLLADA. Cheetah3D seems the exception.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #18
Wow, thanks for all that info yopyop, much appreciated! Smile
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #19
Good to hear Cheetah will support it. Its the only upgrade I'm getting this year ... pay as you go recession blues. Smile
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #20
Two first-time posters, knowledgeable about collada here in this thread! IDG has some lurkers!
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #21
I get shivers down my spine every time someone calls an XML based format/schema a "language". It's certainly not a *programming* language.

As the docs say,
Quote:COLLADA defines an XML Namespace and database schema

And as far as the Collada DOM is concerned, while very flexible, it's terribly inefficient to work with and to render. It is certainly not a runtime structure you'd want to have in your game. The core difficulty with Collada *is* the object model. Parsing XML isn't difficult these days, but the Collada DOM uses a lot of indirection, and it is often redundant and inefficient.

So, dunno. Don't use FBX, but similarly to it Collada only solves the very specific problem of exchanging 3D data between applications, but not the problem of getting it to the screen efficiently.
Quote this message in a reply
Member
Posts: 268
Joined: 2005.04
Post: #22
DoG Wrote:So, dunno. Don't use FBX, but similarly to it Collada only solves the very specific problem of exchanging 3D data between applications, but not the problem of getting it to the screen efficiently.

This.

Collada and FBX are certainly full-featured, but they're not exactly built for games. Slow and complicated to load, and the formats don't provide anything special for getting the models displayed through OGL.

My kingdom for an open model format, with exporters from every 3D program, that has vertex array ready data that you can send straight to OGL. Oh, and animation capable. With unlimited texture and shader support. And it comes with a free unicorn.

EDIT: Actually, "Unicorn" would be a good name for the world's most perfect model format. Hmmm...
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.06
Post: #23
Quote:while very flexible, it's terribly inefficient to work with and to render.
Quote:Collada and FBX are certainly full-featured, but they're not exactly built for games. Slow and complicated to load, and the formats don't provide anything special for getting the models displayed through OGL.

In addition to offering interoperability between DCC tools, COLLADA offers a content pipeline processing to convert the data between DCC friendly data to run-time friendly data. Run-time applications, such as game engines, are limited in the type of data they can process, often limited to the data types directly offered by the graphics API used (i.e. OpenGL / DirectX).

For example, topology is quite often limited to triangles. DCC tools like higher level of descriptions, such as quads, polygons, surfaces such as Splines, or even BREP for CAD.
Even within the triangle descriptions, engines are often limited to a single index per vertex, while COLLADA allows for multiple indexes in order to save space, share data...

There is no way to avoid the conversion step between the data types in DCC Tools, and the very restricted types used in game engines. The question is where is this processing should take place.

One way to do this is to limit the exporter to only expose what is needed for a given engine, and do all the processing within the exporter. This is the first thing that come to mind for an engine developer. Of course this comes with a bag of inconvenience:
- Each engine has its own exporter
- Each engine has its own format
- Each time the engine evolves, the exporter has to evolve
- Flip side, each time the engine evolve all the data need to be re-exported, which often causes headache since a lot of time is lost because of uncompatible versions
- Re-exporting is very costly since it means loading the data back in the DCC and exporting from the DCC (not a light process)

In short, doing the processing of data within the exporter can work for small projects but quickly becomes a burden for medium or large scale projects.

So the question is where to do the data conversion process. The other extreme method is to do export the data in a standard format (COLLADA, FBX) all do all the processing in the run-time/game-engine. This is indeed a large task, and each developer has to create his own loader and processing, and spend time understanding parts of the COLLADA spec that they do not care about.

So a better method is to process the data off-line, outside of the exporter, and outside of the engine. Just like code is compiled, one need a compiler for data. Example of this for COLLADA is the refinery conditionning pipeline. The idea is to be able to have a common configurable set of conditionners that can be shared (open source) among all developers.

This is where COLLADA is very different from all other formats, since it is possible to take a (raw) COLLADA file, process it to make the data more convenient for run-time processing, and still save this data in the same language. An additional step that is engine specific can be added to in-fine save the data in the prefered engine specific binary format. Examples of that are Google O3D COLLADA Converter, or the Ogre COLLADA converter.

Also you can have a look that the COLLADA for XNA C# source, which contains a de-indexer that convert multi index triangles to single index DX buffers ready for drawing, directly within the COLLADA datastructure in memory. It is only about 100 lines of code, and it is a demonstration that COLLADA data model is powerful enought to both represent data types that are friendly to DCC, as well as data-types that are ready for low level graphics API consumption.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #24
yopyop Wrote:So a better method is to process the data off-line, outside of the exporter, and outside of the engine.

Yes, for game engines, off-line processing to binary is ideal for production releases. For development however, sometimes it is nice not to have the extra off-line processing step in the way.

Personally, and this might sound a little strange, I don't really care too much about whether the format is overkill or unwieldy; just that it's solid and wide-spread, which is why I've been okay with putting up with FBX so far. In fact, as you mention, such a standard file format *is* overkill for games because it's primarily for interchange between DCC applications and as such, isn't optimized for games. From a game development standpoint, all I really really care about is that the format is "the standard" across multiple 3D editors (DCC tools is probably more correct). I don't want to write an exporter for each DCC app -- heck, after my experience with Maya API/MEL I don't want to write even *one* exporter ever again, much less several. An offline converter is perfectly acceptable to me, and the file format need not be optimized for games in any way for me to be on-board with it.
Quote this message in a reply
Nibbie
Posts: 3
Joined: 2009.06
Post: #25
This may be of interest to this group.

https://collada.org/public_forum/viewtop...=13&t=1435

Note that this is taking advantage of the next gen collada parser and claim 4x speed up from the previous loader.

If you care about spead of loading check this out, this is most likely also much faster than FBX loading. Currious about your findings.
Quote this message in a reply
Moderator
Posts: 3,570
Joined: 2003.06
Post: #26
Thanks again yopyop!

That is really impressive. Looking at the source code it is also impressive in that the guy writes fairly clean C++, which is a rather rare sight these days... Sneaky
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,139 Sep 22, 2010 10:47 PM
Last Post: OneSadCookie
  Snow Leopard and OpenCL TythosEternal 4 4,074 Jun 12, 2009 08:05 AM
Last Post: AnotherJake
  Objective-C Collada Importer DoG 3 6,495 Feb 27, 2009 01:35 AM
Last Post: skumancer