Collada

Tony Parisi writes "Remi Arnaud and Mark C. Barnes' Collada: Sailing the Gulf of 3D Digital Content Creation is a great first book on a new technology for entertainment applications. Collada is a file format for the exchange of 3D game and interactive content, developed by a consortium of companies including Sony and leading digital content creation software vendors. Collada acts as an intermediate format between DCC tools and end applications — thereby promising to solve ages-old productivity issues in the 3D content pipeline. The authors have done a thorough job explaining this problem, and how Collada solves it, in an introductory book that is well suited for a technical audience building advanced 3D tools and applications." Read the rest of Tony's review.

Collada: Sailing the Gulf of 3D Digital Content Creation
author	Remi Arnaud, Mark C. Barnes
pages	240
publisher	A K Peters
rating	9
reviewer	Tony Parisi
ISBN	1568812876
summary	Describes Collada, a new format standard for 3D graphics content

When I first heard about Collada in 2004, I was skeptical. I am no stranger to 3D file formats: I co-created VRML in 1994 and continue to push that rock up the hill with X3D, an XML-encoded 3D format for the web. After a decade of getting arrows in my back blazing this trail, it felt like the last thing the world needed was Yet Another 3D File Format. Developers in the game world, and to a lesser extent, the DCC tools world, had largely turned their backs on standards of any kind — the proverbial tough crowd. However, the laser-focus of the Collada design team seems to have paid off: the industry now has a common exchange format for game assets, and there is hope yet for developers who would rather spend their time building games than building tools to make games. This clarity of focus on the design comes through in the book as well. Arnaud and Barnes, principal designers of the Collada standard, have written a detailed and lucid book that explains Collada from concept through implementation.

Any first book on a new technology has the unenviable task of explaining the *why* of it, as well as the what and the how. The big risk there lies in devoting too much of the book's content to the background and overview materials before getting to the meat. The book excels in this regard, by clearly laying out a compelling case for an intermediate format, but quickly, so that experienced engineers and managers can get the point, and then move on to the useful information that comprises the bulk of the material. I suspect that Collada will serve as the seminal text on the subject for some time to come, and therefore the overview material is essential. However, if this had only been a survey or introductory book it would have missed the mark with its target audience — some of the busiest and results-oriented developers on the planet, people for whom what-is-it and how-do-I are where the rubber hits the road.

Most of Collada is devoted to explaining the format's core concepts: geometry, scenes, animations, and physics. These are the building blocks of all interactive graphics content. The book walks through these in a straightforward progression; I found it very easy to follow. After covering the basics, it combines them into useful end-to-end examples that give prospective implementers a sense of what it would take to build Collada tools. It worked for me anyway: we will be building Collada support into our products based what I learned in here.

Midway through, the book goes into a bit of a jag on the subject of effects. In its simplest form, the concept of effects simply refers to an object's basic visual appearance: color, textures, shading etc. Unfortunately, in modern graphics, nothing is ever that simple. What begins as a discussion about those basic concepts quickly cascades into a deep-dive on programmable shaders, effects-packaging techniques, multi-pass rendering, and profiles — the latter presenting a glimpse into the sausage-making stuff of standards and hardware consortia, things mere mortals were not meant to know. This is not really the fault of the chapter's author (contributor Daniel Horowitz from NVIDIA), but more a side-effect of the intensity of the subject matter. I am wondering if this all could have been handled better in a separate book or an appendix. The saving grace here is that it's at this exact point in the current printing of the book that we get the color plates — 8 gorgeous images courtesy of the biggest names in graphics: Epic, NVIDIA, Alias and the like. But that's the beauty of 3d graphics: when the math gets hard... go to demo!

Collada gets back on track with 2 excellent chapters on animation and physics — again, at just the right level for a seasoned 3D toolmaker like me. The final chapter explores the Collada content pipeline: how different Collada-aware tools can be mixed and organized to create the final content from all the original assets. Here the orientation of the book moves from a focus on specific features to a system view of how to assemble disparate software tools into working production solutions. Managers and decision makers reading the book will benefit most from this chapter, which I found to be not only thoughtful but provocative, as it touches on the issues at the heart of Collada's mission: how to make robust, open, cost-effective systems for creating rich content that lasts the test of time. The book also contains a handful of informative appendices on Collada plug-ins for the major DCC tools such as 3ds Max and Maya. The plug-in appendices cover build steps, supported features, practical use scenarios, and known bugs and issues.

Other than that effects digression, my only critique — a minor one — is that it is a bit heavy on the XML. From the second chapter, the book dives into details of XML syntax, document types, schema and such, and never looks back. I understand where the authors are coming from: rather than invent a pseudo-code to illustrate the concepts (which then would have to be translated into XML for the working examples anyway), it's more economical to just get the reader up the ramp with XML and get on with it. I am willing to believe that graphics-savvy readers who are not conversant in XML — and I am betting there are still many, many such 3D geeks out there — will be able to get over this quickly. You should: XML is *the* way to store and transmit data, period, full stop. Just in case you are naïve about XML, the authors have actually put in a short primer on it in the second chapter. It's good, and it should be enough to get you through.

I highly recommend this book. If you are a programmer with a reasonable understanding of 3D graphics programming and/or authoring using 3D scene graphs, you will be able to learn the basics of Collada. If you are an experienced 3D toolmaker, Collada contains everything you need to get up and running to build your game, game engine or content pipeline tool. If you are a manager or decision maker, you get the added comfort of knowing that — finally — you just might be able to write that tool once and not over and over again.

Tony Parisi is a software architect and entrepreneur who loves to solve hard problems. Tony's company, Media Machines, is building an open source, open standards-based platform for delivering 3D virtual worlds on the web. Tony is the co-creator of VRML, the original standard for 3D on the web, and is a principal developer of X3D, the XML-based successor to VRML for building web-based 3D virtual worlds.

---

You can purchase Collada: Sailing the Gulf of 3D Digital Content Creation from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

XML

[Trillan]

XML is *the* way to store and transmit data, period, full stop.

Sure, it's a good way, but could we please have an end to silly and blatantly false assertions like this one?

Re:

[hansamurai]

Can you provide a format that is able to store and transmit graphical data in a way that is easy for a computer and a human to parse and read?

Re:

[Anonymous Coward]

Some of you people are fucking morons. Do you want it easy to read, or do you want it fast? It is painfully slow to parse vertex data in a human readable XML format!! Where do you draw the line? Why not sure DTX-compressed images in XML too? Humans don't need to read this type of stuff anyway. When are you people going to get it? Console game developers still store game data on the media in a native buffer format just for performance reasons. Do you think WoW would load up as fast if it stored anima

Re:

[Trillan]

The claim was "XML is *the* way to store data, period, full stop." Period.

Depending on the structure of the data needing to be stored, XML can be very verbose and highly redundant. The hierarchal model isn't necessarily ideal, either, depending on the application. Relational models often work better.

Depending on the nature of the data (and again, the claim is "...data, period, full stop"), there's a bunch of options. If the data is very simple a simple delimited text file may be better. If rapid searches an

Re:

[Gospodin]

If rapid searches and transformations are required, SQL may be better.

Could you send me a file in SQL format?

Re:

[Trillan]

Sure. Queries are just text, after all. Or did you have in mind a particular binary format?

Re:

[Gospodin]

OK, M[r|s] Deliberately Obtuse: SQL is not a data-exchange format, it's a query language. SQL is to relational data as XQuery is to XML. So it's a bit silly to say that if you want to exchange relational data, you should use SQL.

Re:

[Trillan]

Actually, a table serialized as SQL queries is, in fact, a data exchange format. (A pretty useful one at that; it solves certain problems very nicely.)

Re:

[Gospodin]

Hmmmm, interesting. I don't see the advantages over XML if you do this, though. In fact, it seems worse (to me). What problems do you see this technique as solving?

Re:

[Trillan]

The main one I found was it allowed me to have extremely fast random access and changes, while simultaneously imposing some order and offering features like SQL triggers. The SQL engine we were using (SQLite) was also more portable than the XML parsers we looked at. (We needed Mac Classic and Palm, for instance.)

So why not just use SQLite's binary repestation? I wanted to avoid being tying the database to a particular version of SQLite, or even (as much as possible) SQLite at all. The time to convert the da

Re:

[Trillan]

Oh, wait. Are you really trying to say that "SQL queries aren't the same thing as SQL"? I read it that way at first, but I thought I wasn't giving you enough credit. If that's really what you mean, that's technically true - but it is so pedantic as to be completely useless. Did you really have a difficult time understanding what I was saying?

Re:

[Thundersnatch]

CREATE TABLE genus (genus_id int, genus_name varchar(100))
INSERT INTO genus
VALUES (1, 'Populus')
CREATE TABLE trees (tree_id int, tree_common_name varchar(100), genus_id varchar(100), species(100))
INSERT INTO trees VALUES (1,'Eastern Cottonwood',1,'deltoides')
INSERT INTO trees VALUES (2,'Common Aspen',1,'tremula')

ANSI-standard SQL as a data exchange format for relational data isn't really any more verbose than XML plus DTD, and a lot more readily usable by many relational datbase systems...

Re:

[Thundersnatch]

Okay, I know I screwed up the data type of genus_id, but you get my point...

Re:

[GeckoX]

If you ignore context maybe.

As someone else mentioned, it was worded that way to get you to NOT think about xml...as it was already chosen as the data transfer format of choice for Collada. IE: Trust that the people that worked on this put the required thought into choosing to use XML. There is no point in arguing about the implications of XML in general as people are for whatever asinine reason.

Re:

[LordOfTheNoobs]

(send-image-data
'( :box
:id 37
:points (
( :x -5 :y -5 :z 0 )
( :x 5 :y -5 :z 0 )
( :x 5 :y 5 :z 0 )
( :x -5 :y 5 :z 0 ))
:color ( :r 50 :b 100 :g 150 )))

?

Re:

[Lazerf4rt]

Can you provide a format that is able to store and transmit graphical data in a way that is easy for a computer and a human to parse and read?

No, and neither can XML.

When a human "reads" formatted data, the human is not reading the fucking data off the hard drive with their eyes. The computer reads the data first, then presents it on a graphical display, in a human-readable way. Even when you read text files or XML, the computer has to do this for you. It just so happens that for text files, there are a

Re:

[jo42]

And, pray tell, why would a human want to parse the XML of a 100 page word processor document, or a 10,000 vertex 3D object?

Don't be a Bush.

Re:

[Chris Burke]

"period, full stop."

Are both almost always code phrases for "What I just said would be utterly retarded to takes as a tautology which you will realise if you think about it for three seconds, but I would much rather you just skipped the thinking part and took my word for it. Pretty please."

This is just another example.

Re:

[azav]

For a verbose format, it sure is a pain to read.

For a verbose format, it sure is wasteful of bandwidth in transmission.

Just some observations.

As someone who has used Director's property lists for a long time, it makes me wonder why people use XML at all.

Director property list:
[property:value, ...]
[prop: [prop:val, prop:val,... ] ]

[#imageIndex: 123, #rect: [0,0,320,240], #tags: [ "kitten", "feline", "edible" ], "Main Author": "Alex The Complainer"]

To me, that type of data layout is much more readable. And y

Serialization

[everphilski]

When you are serializing/deserializing an object with many properties, and properties with properties with properties, the ability of an XML file to recurse an arbitrary number of levels deep is nice, versus
[prop: [prop:val: [prop:val, prop,val]]
which is only two levels deep into the first prop... many times if you have structures and the like, it will go deeper and it is no longer really human-readable.

Re:

[azav]

Lingo's property lists are not limited to two levels deep.

I just didn't want to spend too much time typing in sub lists.

You're correct about it not being easily readable but then you have a simple intent based displayer. I wrote one in 1995.

It's not that hard. Like 7 lines of code maybe?

Re:

[everphilski]

Well that is the whole point of XML. Not needing the reader to just dig in and edit it by hand. Machine readable and human readable.

Re:

[PsychicX]

Parent is right. Collada isn't an end-all format. It's meant as an exchange and interop format. You'd have to be an idiot to write a game that uses Collada at runtime. But for feeding between various modelers, processing tools, and the like, it's a perfect format.

Right tool for the job etc etc. You know the drill.

Re:

[abradsn]

Just for the record... It works great as the format in my 3d engine. And I'm not an idiot.

By the way, anyone who loads files in a 3d engine past the initialization load time of the project might be making a bad mistake.

It should be pointed out that it doesn't matter much what format you use in the long run, and also that there are various good reasons to make different choices along the way.

Space is less of a concern now, and will be less of a concern as time goes on. And if this is not true in a given si

Re:

[PsychicX]

Well, if you find multi minute loading times acceptable, and think throwing away the ability to stream efficiently is fine, then by all means go ahead. I'll be over here, building real graphics systems and not toys.

Re:

[abradsn]

Streaming text can and often is faster than streaming binary files from disk. You might find this surprising. I did too. If you are streaming over a network, then god help us all, but I'll give you that it would be a ton slower to stream text as opposed to binary over a network.

Perhaps you are still using C or Pascal though -- where you can actually stream binary "records" from file directly into the data type. (I know that c approaches that problem differently, but it is still fast, so its the same

Re:

[Bogtha]

<sentence type="question">
<word><letter type="capital">W</letter><letter>h</letter><lette r >y</letter></word>
<space/>
<word><letter>d</letter><letter>o</letter></word>
<space/>
<word><letter>y</letter><letter>o</letter><letter> u</letter></word>
<space/>
<word><letter>s</letter><letter>a</letter><letter> y</letter>

Re:

[Trillan]

That was beyond brilliant. However, I suspect you missed encoding the question mark somehow...

Re:

[Fred_A]

could we please have an end to silly and blatantly false assertions like this one?

Maybe get people to read the daily WTF [thedailywtf.com] to teach those lucky enough not to have been exposed to the "let's do it in XML" horror. (Unless you already happen to have a mauve database in which case anything goes)

Re:

[DulcetTone]

XML ... the CSV of Y2K!

no

[Gospodin]

Silly lameness filter requires me to type something...

maybe

[everphilski]

added for completeness

One main contributor not mentioned...

[Anonymous Coward]

is Feeling Software http://www.feelingsoftware.com/ [feelingsoftware.com]. I'm using Collada on a daily basis, and the company makes some of the best Collada tools, importers and exporters and are used by many DCC users. They're either freeware or open-source and downloadble on their website, so heads up for any interested developer out there. They were also involved in the writing of that book and most of the color plates the author mentions are actually theirs.

Re:

[Excors]

To be specific, Feeling Software's exporters (ColladaMax, ColladaMaya) and their COLLADA manipulation library (FCollada) are under the MIT licence. The development process isn't particularly open (their Bugzilla is, but their code repository isn't and you have to just wait until the next official release to get any new fixes), but that hasn't been a problem for me in practice - I've had to make some local changes to get FCollada compiling on Linux, but it's easy to do that and to distribute patches since it

Collada

[faqmaster]

as in Piña? Sounds like a good idea.

Mentioning that you were involved with VRML...

[Assmasher]

...does not lend credibility to your review. Does collada support bones/skinning information or does it just support an extension mechanism (disaster)? Are there exporters/importers available currently? Now, I LOVE XML, but I would never suggest that XML is the best way to go for data 'full stop.' Such statements show inexperience in software engineering, especially given that his speciality is supposed to be 3D over the web LOL. Maybe he was referring to compressed and/or encrypted XML. Probably not,

Re:

[GeckoX]

Just because a group of people took a stab at something way before it's time...come on now. Did you try to put together a markup based 3d standard back in the day? No?

And do you really think that in the interim, these people have learned nothing from their experiences with VRML? It appears they did just that. X3D was a complete fresh start.

And could you keep things in context a little? Please? Taking one single statement completely literally ignoring it's context doesn't make sense. a) This guy deals with w

Re:

[Assmasher]

XML makes zero sense for a 3D content system unless you have an overriding need to make the data human readable in its raw form. Again, I really like XML and i use it for event system communication throughout our enterprise architecture. The people in the 'industry' who know what they are doing? Like who? People who write Collado viewers? People who don't make games, don't make useful visualization products, people who write simple things like a model view. Let's put this another way. People much muc

Re:

[Excors]

Who, exactly, do they think is going to use this besides amateurs and little tools companies (like the ones linked to in the article) who cater to amateurs...?

Sony [scea.com] (PS3 SDK). Epic [feelingsoftware.com] (Unreal Engine 3). Nvidia [nvidia.com] (FX Composer). AGEIA [ageia.com] (physics).

XML provides more than just a way of serialising a tree into text - I've not looked into the details very far, but what I've seen is that COLLADA uses XML Schema for validation, URIs for references between different locations (e.g. defining a piece of geometry, then addin

Re:

[Assmasher]

"Sony (PS3 SDK). Epic (Unreal Engine 3). Nvidia (FX Composer). AGEIA (physics)"

Sony? That doesn't mean anything, Microsoft uses the .X format, but I'm not aware of too many game companies that deliver content in that format or use it in their art pipeline.

Epic? Ships content in Collada format? Uses it for its own art pipeline? I'm just guessing but they probably support using it for mods, right? That the only format they support?

Nvidia? It isn't supported in 1.8, purported to be supported in 2.0. BTW,

Re:

[Excors]

Epic? Ships content in Collada format? Uses it for its own art pipeline?

I doubt anyone would ship it, since it's not suitable for that. I can't find any details of how UE3 actually uses it, so I couldn't do more than conjecture - and most other game developers also appear to keep quite quiet about what technology they're using (at least in public). I've not heard of any other games that have been released yet and are using COLLADA - they [khronos.org] claim that "active users" include "THQ, EA, Konami, NCsoft, DoubleFin

Re:

[GeckoX]

Who exactly is going to use this? Who exactly was involved in it's development? I'd suggest you start there.

Amateurs and little tools companies...riiiight. Because amateurs have such high need for this kind of thing. Little bands of 2 or 3 coders with rendering farms and content creation pipelines.

Fuck you're an idiot. This ONLY makes sense for the big boys in the industry really, and surprise! They're the ones that came up with it!

Read a bit next time would you?

Re:

[Anonymous Coward]

What a surprise the usual amount of FUD flying around.

I have been developing tools for use with Collada for the last 6 months, and have been following it's development for a good year before that.

As a startup Collada provides us with a cheap way to bring our tool chain together. We can rely on data from one tool to make it into another tool unaltered and useable. Being XML it is easy to 'look under the hood' and see if there is any crud and make minor fixes that would be difficult with any of the binary int

Re:

[Assmasher]

"Amateurs and little tools companies...riiiight." - Are you not aware of who is using it at this very moment? Amateurs and little tools companies. Know anybody making PS3 games? I do. They don't use Collada. They don't even touch the Sony SDK if they can avoid it because "it's crap". This is a from a company who have been making games for longer than 6 months, and they have their own pipeline already. As an aside, they do love the PS3 though.

"Because amateurs have such high need for this kind of thin

Re:Mentioning that you were involved with VRML...

[LetterRip]

"People much much more involved in the 3D industry will avoid this format on the simple grounds that it is a generic solution to a problem best solved by specific art pipelines."

Collada is rapidly being adopted because it works great as an open exchange format between 3D content creation tools. Maya, 3DS Max, XSI, Lightwave, Houdini, Blender, all have Collada support - indeed good Collada support is a major selling point of the latest release of XSI.

Since Collada is the native format supported for Sony on the PS3 everyone is also motivated to support it well.

LetterRip

Re:

[Assmasher]

"Collada is rapidly being adopted because it works great as an open exchange format between 3D content creation tools. Maya, 3DS Max, XSI, Lightwave, Houdini, Blender, all have Collada support" - they all (at least 5 of the 6 for sure) have .X file format support as well, that doesn't make either of them good file formats.

"indeed good Collada support is a major selling point of the latest release of XSI." - Doesn't seem to be mentioned on the XSi 6 pages. I did see a blurb about integration being added in

Re:

[functor0]

Who, exactly, do they think is going to use this besides amateurs and little tools companies (like the ones linked to in the article) who cater to amateurs...?

I know of at least two production companies that use a proprietary XML format. ( http://www.xsi-blog.com/?p=15 [xsi-blog.com] ). If Collada had existed at the time, maybe they would have used Collada instead.

Re:

[Excors]

It does support skinning - I've actually just finished writing a converter from COLLADA into a custom format for a game (since COLLADA is not suited (nor designed) as a final format for distribution to users; it's for interchange between development tools where efficiency isn't so critical), and that handles skeletal animations using the standard features with no need for extensions. There are importers/exporters here [feelingsoftware.com] for Max and Maya, here [illusoft.com] for Blender, elsewhere for others. It's also the native format for

Re:

[Assmasher]

Supported? I guess technically you could say that but that's like saying that .X supports skinning. ;)

In my experience, people who are using art pipelines to generate content for serious commercial applications (whether games, visualization, or other verticals) will avoid this format because when you get down to it, if you're a 3D developer writing your own file format is trivial. Writing your own exporter is NOT; however, there are many exporters than are quite good at their job which you can use to prod

If Collada is ....

[j-min]

If Collada is a file format for the "exchange of 3D game and interactive content", what's the file format for a descriptive submission title?

Now they publish

[monopole]

While Collada is a way neat concept, the specification/documentation sucks big time.
Having implemented a parser/importer in Python from scratch I can attest to a huge amount of ambiguity in the 1.4 spec.
That said, once you figure it out COLLADA is really sweet.

COLLADA Physics

[erwincoumans]

In case you are interested: Blender 2.42 and later supports basic COLLADA 1.4 export/import including physics information. Also CreateDynamics and ColladaMaya supports such physics information. The open source Bullet physics engine uses COLLADA-DOM and libxml to import/export such physics files. A less bloated approach is using TinyXML, that's the approach of CreateDynamics tool. Erwin

Collada Academic, not only games

[ALoopingIcon]

Beside big players, like Maya, 3dsmax and Blender, I would like to remark that Collada is gaining a momentum even in the academic environment. MeshLab ( http://meshlab.sourceforge.net/ [sourceforge.net] ) , for example, is a Collada enabled open source tool aimed to the processing of large 3D scanning meshes for Cultural Heritage applications, like documentation, reproduction, restoration planning and didactical uses of 3D technologies.

XML is the best way to store data?

[mrobin604]

I worked on a game that was created using a middleware package that used XML as a file format for level layout. As we got into full production, and the levels got populated, it would often take 20-30 minutes to load a level into the editor, most of which time was spent opening a ton of XML files and parsing strings.

Another company I worked for had a proprietary geometry/animation format that was ASCII based and very verbose. The tools to process this data were also very slow, probably at a minimum 10x slowe

Re:

[Excors]

Besides this, your file sizes will balloon amazingly, as XML/ASCII doesn't have a very good information density when compared with binary data, which doesn't care about formatting and keywords.

It's not good, but it's not quite as bad as one could imagine. Most of space in COLLADA is not XML tags - it's the lists of numbers (arrays of coordinates, indexes into arrays, etc), and those tend to be what increase when you get millions of vertices. The coordinate data for a very small object looks like:

<sourc

Re:

[kellererik]

Don't get me wrong here, but (having worked in the game-industry myself) I was always under the impression, that COLLADA is meant for exchange and use in workflow-pipelines in general. Who prevents you to convert the final result into something that loads faster?

Or to put it more bluntly, batch-convert the stuff you are working on, to work on it and convert it back to COLLADA when it's going back into the pipeline.

I might be mistaken here, but that's how we saw the format and its best use.

my 2 cents and a d

Re:

[Excors]

I've only been working on amateur game development, where all the people are spread around the world and have different tools and there isn't really a traditional art pipeline. Batch conversion doesn't seem as suitable if everyone would have to download hundreds of megabytes over the internet each time the converted data changes, which is why we [are planning to, in the next few weeks] distribute just the COLLADA files to the people involved in development, and their copy of the game automatically converts

Re:

[kellererik]

I agree one hundred percent. It seems, that using Collada from end to end for development, is ideally suited for your kind of setup.

I wish you guys the best of luck for your project. Maybe you should think about writing an article how you made use of Collada. Would be the kind of "How we did it" stuff everybody loves to read. ;-)

best,
Erik

Re:

[mrobin604]

I've only been working on amateur game development, where all the people are spread around the world and have different tools and there isn't really a traditional art pipeline.

In your situation, I definitely can see the benefit of Collada for interchange between different environments. I think going forward your distributed development model will be more the norm, as art outsourcing gets more popular (though I'm guessing the environments won't be quite so heterogenous as what you have to deal with!). But fo

COLLADA

[*BBC*PipTigger]

I worked on the specification a little and have advocated use of the standard at several development studios I've worked at (primarily for PS2, PSP, and PS3 titles but it would help for simultaneous cross-platform projects too).

I've seen lots of complaints that the format is not necessarily any better than Microsoft's .X format because most DCC tools can import either one just fine. This misses the *exchange* emphasis of COLLADA (i.e., that it can be successfully *exported* by each tool too!).

Of course XML

How will this affect X3D?

[Peter Amstutz]

Hi Tony (if you're still reading comments), I think we met at the X3D Symposium last April.

How do you think Collada will affect people's interest and involvement in X3D? It's evident that VRML/X3D has failed to gain traction in the 3D entertainment sector, and that Collada's focus here means that it will probably (hopefully) be much more successful. Also, from a gut-reaction level, Collada is much cleaner and doesn't have some of the silly baggage that you find in X3D (such as delimiting lists with "-1" a

Re:

[Tony Parisi]

Peter, I see the potential for great synergy between X3D and Collada. Collada is squarely in the domain of interchange, while X3D is much better for downstream deployment. I would not use the Collada data structures at runtime, whereas I do use X3D for that. I wouldn't say that X3D has "failed" with entertainment as such, primarily because there was never really any attempt to push it into that market. It would be more accurate to say that there was enough lack of interest a few years back that the Web3D

Thanks

[luther2.1k]

Thanks for reminding me of the collada project, I'd forgotten about it and it's good to see how well it's coming on. It should be easy to implement a reader and writer into my own software and it's really refreshing to see a human readable format that is being developed by and for the game authoring community: the VRML effort always seemed out of touch as far as what was going on in 3D games, perhaps through ignorance, snobbery or maybe just that 3D in games were quite immature back then.
It's also refresh

COLLADA Review Should Have Been Posted In Games./.

[*BBC*PipTigger]

I know this is a book review so HTTP://Books.SlashDot.Org makes sense but this standard is going to be most relevant to more people who are consistently reading HTTP://Games.SlashDot.Org than those frequenting any other section of SlashDot. Oh well.

-Pip