Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Collada

samzenpus posted more than 7 years ago | from the make-it-a-3d-world dept.

Book Reviews 79

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.

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.

cancel ×

79 comments

Sorry! There are no comments related to the filter you selected.

lol vrml (0, Insightful)

Anonymous Coward | more than 7 years ago | (#17316826)

lol vrml

XML (3, Insightful)

Trillan (597339) | more than 7 years ago | (#17316932)

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:XML (1)

hansamurai (907719) | more than 7 years ago | (#17316950)

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:XML (1, Insightful)

Anonymous Coward | more than 7 years ago | (#17317080)

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 animations, geometry, and textures in XML? I think not.

Re:XML (2, Insightful)

Trillan (597339) | more than 7 years ago | (#17317096)

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 and transformations are required, SQL may be better. Define the requirements and pick the format; don't just say "XML, period, full stop." That's simply insane.

Re:XML (1)

Gospodin (547743) | more than 7 years ago | (#17317394)

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

Could you send me a file in SQL format?

Re:XML (1)

Trillan (597339) | more than 7 years ago | (#17318762)

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

Re:XML (1)

Gospodin (547743) | more than 7 years ago | (#17319094)

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:XML (1)

Trillan (597339) | more than 7 years ago | (#17319112)

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:XML (1)

Gospodin (547743) | more than 7 years ago | (#17319518)

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:XML (1)

Trillan (597339) | more than 7 years ago | (#17319682)

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 data to and from text wasn't beyond user expectations, considering we were replacing a system that loaded all document data into RAM.

The SQL-database-as-text format is a good option for writing a document-based application where the data can be stored in a relational database; while it definitely wouldn't work in all cases, it is worth considering.

Unfortunately, the product got shelved before it could be completed (although we did have our data flowing between SQLite's binary representation and SQL queries). I hope to try the technique again one day...

Re:XML (1)

Trillan (597339) | more than 7 years ago | (#17319156)

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:XML (1)

Thundersnatch (671481) | more than 7 years ago | (#17320014)

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:XML (1)

Thundersnatch (671481) | more than 7 years ago | (#17320068)

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

Re:XML (1)

GeckoX (259575) | more than 7 years ago | (#17317396)

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:XML (0)

Anonymous Coward | more than 7 years ago | (#17317398)

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?

<?xml version="1.0"?>
<!DOCTYPE revvvoool SYSTEM "http://www.somesiteyoucantsee.com/revvvoool">
<r evvvoool xmlns="http://www.somesiteyoucantsee.com/revvvoool " xmlns:rev="http://www.somesiteyoucantsee.com/">
      <rewtdfg>9876yfhgf87t*&yagw8706Rjhaejva987zdfnmzbd </rewtdfg>
    <7rjfhcf>&^mhfmsenobfufiu75*^ 8aejyhgalu7aufagfdjhy5dcu6z a zu6aauau765c6a</7rjfhcf>
    <5698serjbxdf>y</5698serjbxdf>
    <22e>*,g*</22e>
    <lishedkn>78e49eidkdmdmd9ekjemd</lishedkn>
    <ertmnbdfg>
        <jfyt5h>d56dfhcgncvg</jfyt5h>
        <jfyt5h>6983475034iu3o49587048503498570349503495u0 34ith908t748t038it</jfyt5h>
        <jfyt5h>4592865934jb5349o5y3iu4gtbk3hbgfi8w7yt4tiu wgbri7wytrwufbiw7ft9w8g</jfyt5h>
        <jfyt5h>4586rqw358rvbwkfugw987rtiwkhbrwi7ftyiwkbfw i7ftiwugfb9ow378r</jfyt5h>
        <jfyt5h>4w5698w347y5kw4jbfi7wtf9iwubfiw7yftiwkbcil 7woft8wiyugfwhgfi6fg</jfyt5h>
        <jfyt5h>hp9n8syrtiusrbgffhtyb4t78awyhtrvkuwybftw84 7ftwauygjme7tvwkuycgwaf</jfyt5h>
        <jfyt5h>gskui6ert8s7hfbvsi76futgswiuyfjgsmjfygsi6t f7ts6yugfvjmshvgi7w6</jfyt5h>
        <jfyt5h>g67istrfgsmhgvcik67stfuskymj skux6fts7iugfvsngfvsy6tfusyvfusk6v</jfyt5h>
        <jfyt5h>bgfydf7ydrjn7rydr6ygdry456457789673536358r uuwe576ufjdfgjhfgjfd</jfyt5h>
        <jfyt5h>fgjdruer6ufndf67rsse56yrsygf6ybhd5r67h4egr njdtmnu5sdr7bsy</jfyt5h>
        <jfyt5h>xft756nrnm74w75f456gv7xrbxd56er56vfex56bn7 gcghjbftyyvdrvtydxrty</jfyt5h>
        <jfyt5h>kyfo7t890k789k789j569kl66hgw45674bwyse5yvs 474hb8inr678jf6j8ej5jb</jfyt5h>
        <jfyt5h>r57h4b567w457mn5dhg458nnbd3s7bvge57e56mnnb 7bd576df57hg7d57e4s6f3</jfyt5h>
        <jfyt5h>564h564wymryjnmrt68mkd5hg7e7jhbe467fv4nbub nsvd5bnh76nbtmtumnftydr</jfyt5h>
        <jfyt5h>ftynbue56mn75hg7e55yungcbvxe6bns4ve6bvez6v seb6enw</jfyt5h>
        <jfyt5h>fbghnrt7udr8m5678md5vzwctzrhgzsdtes65w4626 7qbtdr675dtm97ndr</jfyt5h>
    </ertmnbdfg>
</revvvoool>
Parse that dipshit.

Oh yeah, XML is a panacea. It is the solution to all the worlds file format problems.

Forget plain text it's useless! Forget binary, its useless! XML rul3z! l33t c0d3rz use XML!!!!111!!!

Re:XML (2, Insightful)

LordOfTheNoobs (949080) | more than 7 years ago | (#17317926)

(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:XML (1)

Lazerf4rt (969888) | more than 7 years ago | (#17318248)

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 lot of tools to present it to you (Notepad, vi, emacs, etc).

With any formatted data, you need tools to manipulate that data. If this realization makes you choose XML for anything and everything, you're just proving you're an inexperienced developer who can't find the right tools for the job. And in fact, you'll notice wherever there is XML, there is usually a lot of shitty code, because the people who choose it are inexperienced. It's a real correlation.

Not to mention, in the real world, XML files usually end up with nodes like this: <encodeddata>a0e7f6253b43c1078...</encodeddata>

Anyway, I'm sure Collada makes nice use of XML to represent 3D data, but let's not overstate the usefulness of XML.

Re:XML (1)

jo42 (227475) | more than 7 years ago | (#17325356)

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:XML (2, Insightful)

Chris Burke (6130) | more than 7 years ago | (#17317232)

"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:XML (1)

azav (469988) | more than 7 years ago | (#17317830)

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 you can even parse it to compress the data into a lookup table so that when transmitted, it takes up less space.

If one were to create a viewer to display and the properties and data with intending, it is not that hard at all.

Visually, this looks more compact and readable (to me). Transmission-wise, there is less text inticating the opening and closing tags resulting in a less bandwidth heavy solution.

Sure, I use XML but when compared to Lingo's prop lists, I really don't get the appeal of XML as a data storage format.

Serialization (1)

everphilski (877346) | more than 7 years ago | (#17318138)

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:Serialization (1)

azav (469988) | more than 7 years ago | (#17321878)

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:Serialization (1)

everphilski (877346) | more than 7 years ago | (#17338314)

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:XML (0)

Anonymous Coward | more than 7 years ago | (#17318150)

The appeal is that I can see hierarchical relationships in the data, and it (most of the time) is easier to figure out what the original author intended the data to be used for.

What you describe is basically a text file. And I like text files. Sometimes I use them without the properties and the tags and the markup or whatever. Sometimes that makes sense.

Most times though, I use XML. It is easy to parse in my language of choice C#.

*Begin rant about past experience*
And I can be sure that no idiot developer working for some retard company can break my code 10 years down the line because ultimately it is a text file.

*End Rant*

If it were 10 years ago, then properties and comma delimited data would be the best that I could do, and I probably would have stuck with them for a while.

Re:XML (1)

PsychicX (866028) | more than 7 years ago | (#17317930)

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:XML (1)

abradsn (542213) | more than 7 years ago | (#17318332)

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 situation, text can be easily compressed. Reading in the xml format is fast and getting faster, so load times are going down. The format easily accomidates extensions. The format includes a great number of well thought out concepts that makes it easier to work with.

One other thing to point out is that, just because the original developers of the format were shortsighted in its application does not necessarily mean that other very useful applications are not available.

The C programming language is a good example of that.

Re:XML (1)

PsychicX (866028) | more than 7 years ago | (#17319562)

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:XML (1)

abradsn (542213) | more than 7 years ago | (#17321034)

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 for my purpose.) Text, and binary both still need to be loaded and parsed (except with c), and maybe your method calls stream directly to memory. I don't know. Nowadays we like this thing called portability.

By the way, I don't have any problem with my load times. Loading happens basically immediately for me. Perhaps I'm using optimizations that you haven't thought of, but I doubt it. More likely, it is that you are making incorrect assumptions.

Re:XML (2, Insightful)

Bogtha (906264) | more than 7 years ago | (#17318864)

<sentence type="question">
<word><letter type="capital">W</letter><letter>h</letter><letter >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></word>
<space/>
<word><letter>t</letter><letter>h</letter><letter> a</letter><letter>t</letter></word>
<punctuation>?</punctuation>
</sentence>

Re:XML (1)

Trillan (597339) | more than 7 years ago | (#17318964)

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

Re:XML (0)

Anonymous Coward | more than 7 years ago | (#17320582)

Why the hell would you need raw 3D data to be human readable? thats what xml does by putting tags around the damn stuff!
""
stick to binary for hells sake. If I want it to be visualised, I'll use a damn renderer

Re:XML (1)

Fred_A (10934) | more than 7 years ago | (#17322918)

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:XML (1)

DulcetTone (601692) | more than 7 years ago | (#17324622)

XML ... the CSV of Y2K!

one word subjects... (0, Offtopic)

CrackerJackz (152930) | more than 7 years ago | (#17316936)

can we please start using more than just one word subjects? I know its a such a pain to come up with titles, but come on...

no (0, Offtopic)

Gospodin (547743) | more than 7 years ago | (#17317456)

Silly lameness filter requires me to type something...

Yes (0)

Anonymous Coward | more than 7 years ago | (#17317484)

We certainly can.

maybe (1)

everphilski (877346) | more than 7 years ago | (#17317508)

added for completeness

One main contributor not mentioned... (1, Informative)

Anonymous Coward | more than 7 years ago | (#17317012)

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:One main contributor not mentioned... (1)

Excors (807434) | more than 7 years ago | (#17317430)

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's open source.

An alternative to FCollada is the COLLADA DOM [sourceforge.net] library, under the SCEA Shared Source License [scea.com] , which is similarly open.

If you like Pina Coladas... (0, Offtopic)

EraseEraseMe (167638) | more than 7 years ago | (#17317174)

Don't read this article because it is absolutely NO alcoholic content whatsoever!

My kingdom for a rum and eggnog!

Collada (1)

faqmaster (172770) | more than 7 years ago | (#17317190)

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

Mentioning that you were involved with VRML... (1)

Assmasher (456699) | more than 7 years ago | (#17317278)

...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, not if he had anything to do with that disgusting blob of a file format called VRML. Maybe I should say what I really think...? ;)

Re:Mentioning that you were involved with VRML... (1)

GeckoX (259575) | more than 7 years ago | (#17317500)

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 web technologies. xml makes a LOT of sense for enabling and defining a web enabled 3D format. b) Collada is an interim file format designed by a bunch of people in the industry that kinda know what they're doing...they chose XML, and for what should be obvious reasons, the reviewer did not want people to focus on that particular design choice because it would be completely and utterly pointless.

Re:Mentioning that you were involved with VRML... (2, Insightful)

Assmasher (456699) | more than 7 years ago | (#17318008)

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 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.

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...? No game company is likely to use it. No visualization product company is likely to do more than *possibly* add import capabilities for the format. It really is just another file format.

Re:Mentioning that you were involved with VRML... (1)

Excors (807434) | more than 7 years ago | (#17318612)

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 adding several instances of it into a scene definition - and then changing it into an external URI if you don't want everything in the same file, or if you want to point to binary data instead of more XML, and having the standard XML tools deal with that correctly), and you can stick custom bits of XML into certain extension points (which standard tools can't parse but can pass along unchanged for later tools). You could do all that without XML, but the designers decided it would be more successful if they did use it.

If your artists can export a model from 3ds Max, load it into FX Composer and tweak the shaders to make it look good, load it into a physics simulator to make sure it reacts sensibly, then have it converted into the optimised native format for whatever engine you're using - and if you're no longer constrained in choice of tools (maybe you want to change from Max to Maya, or support a modding community with Blender, or load assets from your last game into your new engine) because they all support the same standard format, and you don't have to write all the code yourself - then it seems like it can have a practical benefit. I'm sure it doesn't work perfectly in practice, and it's not going to give groundbreaking improvements to the game development process, but it appears to go a long way in the right direction and it looks like it's gaining some real support.

Re:Mentioning that you were involved with VRML... (1)

Assmasher (456699) | more than 7 years ago | (#17319282)

"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, this tool also supports .X, so this certainly isn't validation of Collada being something viable for commercial 3D usage.

AGEIA? I presume their SDK and/or tools can let you drop in Collada files? Again, they probably support other formats as well, ergo it isn't like they're choosing Collada because it is a good file format as much as it is a format likely to be used by amateurs.

Now, I'm certainly not trying to use the term 'amateurs' in any derogatory fashion, we were all amateurs at one time or another, but there's a huge difference between hyping a file format because it solves problems that others cannot and hyping it because SONY is crapping eggrolls over XNA.

"COLLADA uses XML Schema for validation" - Why? Why would you need XML to do this? Standard file importer code will tell you if you encounter an invalid file.

"URIs for references between different locations (e.g. defining a piece of geometry, then adding several instances of it into a scene definition - and then changing it into an external URI if you don't want everything in the same file, or if you want to point to binary data instead of more XML" - Why would you need XML to do this? 3D file formats have been doing all of these things for years. External references, instancing, et al.

"...and having the standard XML tools deal with that correctly..." - Why? Why would I want to use 'standard XML tools' to view/edit my art asset? Especially given that the file format, although XML, is very difficult to follow for a human unless the file contains the very simplest geometry, and references.

"If your artists can export a model from 3ds Max, load it into FX Composer and tweak the shaders to make it look good, load it into a physics simulator to make sure it reacts sensibly, then have it converted into the optimised native format for whatever engine you're using" - Why would I want to make my artists work so hard? If you've got an engine and you'd like to make it easy for the artists to see what their assets will look like, you simply integrate your engine with their art tool of choice. This is relatively simple to do. No exporting, dropping out of MAX/MAYA/XSi, no starting up another app, tweaking shaders, exporting to physics simulator (which you presumably wrote), and back... The whole thing runs in your art tool. This has been common for years now.

"...and if you're no longer constrained in choice of tools (maybe you want to change from Max to Maya, or support a modding community with Blender, or load assets from your last game into your new engine) because they all support the same standard format, and you don't have to write all the code yourself - then it seems like it can have a practical benefit." - But you are constrained, unless the tool makers start making Collada exporters, and they do not do things like this, you're constrained by whatever features the person who wrote the exporter provides. For example, using MAX, stacked skin modifiers get baked how? Answer: however the exporter guy wanted which is unlikely to be the way you wanted it done. Unless you're going to do things simply, no tangent space information, normal map animations, et cetera, game development companies are not going to find the format really useful. This is the inherent problem with 3D file formats, if you make them flexible enough for many game companies to use then there's so much interpretation the developer must do that they would save time developing their own art pipeline tools.

"I'm sure it doesn't work perfectly in practice, and it's not going to give groundbreaking improvements to the game development process, but it appears to go a long way in the right direction and it looks like it's gaining some real support." - I think it has great value for people starting in game development or interested in visualization and simulation. It's not likely to be used by a company. That doens't mean it can't, it isn't likely.

What's the benefit of it over .X for example?

The only discernable difference is that .X let's you define your own templates whereas Collada provides a more 'guiding hand' approach by specifying it as part of the format.

Re:Mentioning that you were involved with VRML... (1)

Excors (807434) | more than 7 years ago | (#17320156)

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, DoubleFine, Rockstar", but presumably the relevant games are still under development. COLLADA itself is pretty recent, so I guess it'll be a few years before anyone can really tell whether it has survived and found a place in the industry.

Why would you need XML to do this?

You certainly don't need XML - but it does those things already, and it's already understood and supported well enough that you could write a quick Python script to read a model and manipulate the DOM and spit it back out again, which saves some effort compared to writing yet more binary importers/exporters for every tool that has to process the file. There's obviously drawbacks to using XML, but it's not as obvious whether they outweigh the benefits.

unless the tool makers start making Collada exporters, and they do not do things like this

XSI mentions [softimage.com] it in one of the main features. (They also mention the dotXSI "standard" - it looks like every modelling program has its own proprietary standard for interoperability... COLLADA is the only one I've seen that's somewhat vendor-neutral (but still flexible enough to handle at least some kinds of real data) - I've heard that Sony saw that the vendors themselves would never agree on any neutral standard, which is why they (as people who want to improve the game development process, rather than push their own tools) had to make one themselves.)

For example, using MAX, stacked skin modifiers get baked how? Answer: however the exporter guy wanted which is unlikely to be the way you wanted it done.

I tried a simple test with ColladaMax, with a sphere and two sets of bones and two Skin modifiers. It exports a scene with a Sphere01-node, using the Sphere01-mesh-skin-skin controller with the Bone05-node skeleton. The scene also contains the hierarchy of bones. It says Sphere01-mesh-skin-skin is skinning the Sphere01-mesh-skin object, and lists the relevant bones and the weights and bind pose matrices and things. It says Sphere01-mesh-skin is skinning the Sphere01-mesh object, and gives more weights and things. And it says Sphere01-mesh is a mesh with certain vertex data. (Incidentally, one advantage of XML is that I can actually look at the file in a text editor and see that reasonably complex hierarchy - the actual geometry data is a horrible mass of numbers, but for small scenes it's quite easy to see what's going on. You could make a visualisation tool for any other non-XML format, but it's helpful if there's no need.)

That seems to be fairly close to how it's represented in Max itself. Then you can (/have to) write your own code that loads that COLLADA file (using existing libraries to handle the boring standard bits), and do whatever conversions you want for your particular purpose. It's still a problem if you need e.g. the Character Studio animation curves from Max (instead of it exporting keyframes and you perhaps choosing to fit a curve back onto them) which the exporter doesn't do (because they're too non-standard). At least the exporter is open source and it might be feasible to hack new features in yourself, but it's annoying if you have to do that.

What's the benefit of it over .X for example?

Does .X do anything like the above for skinning? (I'm not at all familiar with it, so maybe it does, rather than collapsing everything into a flat mesh plus weights). There's also support for cross-platform shaders and physics, which seem like they're getting more interest than the geometry side - you could (apparently, I've not tried it) export physics from Blender, view the scene in the Feeling Viewer, then import it into PhysX and use it in a game, which is more useful than just moving some geometry between programs. It's hard to tell what people are really using it for, and what they really think of it, and I'm not involved in professional game development so I don't have the right perspective - but from what I can see, it does seem to be worth at least some consideration, even if it ends up with experience showing it to be less suitable than the normal approaches.

Re:Mentioning that you were involved with VRML... (1)

GeckoX (259575) | more than 7 years ago | (#17318634)

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:Mentioning that you were involved with VRML... (2, Informative)

Anonymous Coward | more than 7 years ago | (#17319352)

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 interchange formats. My only problem is as the reviewer stated that it can be somewhat complicated at times, and that some of the exporters are still quite not up to scratch.

Re:Mentioning that you were involved with VRML... (1)

Assmasher (456699) | more than 7 years ago | (#17319444)

"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 thing. Little bands of 2 or 3 coders with rendering farms and content creation pipelines." - Do you even know what a rendering farm does? LOL. What the hell does a rendering farm have to do with Collada that doesn't apply exactly the same to any other file format?

"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!" - Funny, this idiot worked at SoftImage for 2 years until we beta'd Sumatra (XSi) and Avid bought the company, prior to that I specialized in Virtual Reality for on Irix/Solaris/NT including writing a large number of file importing code back when we 'idiots' had to do things the hard way. As for your extreme naivety, applying that same 'logic' suggests that the .X file format will be used by serious 3D graphics ISVs because a big boy in the industry 'Microsoft' has tools that use it.

"Read a bit next time would you?" - Maybe you should know something about the *professional* 3D graphics industry first before calling other people 'idiot.'

Re:Mentioning that you were involved with VRML... (3, Interesting)

LetterRip (30937) | more than 7 years ago | (#17319114)

"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:Mentioning that you were involved with VRML... (1)

Assmasher (456699) | more than 7 years ago | (#17319366)

"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 5.1x, but that was on a softimage wiki, not XSi's site.

"Since Collada is the native format supported for Sony on the PS3 everyone is also motivated to support it well." - You mean supported by the PS3 SDK.

Re:Mentioning that you were involved with VRML... (1)

functor0 (89014) | more than 7 years ago | (#17321436)

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:Mentioning that you were involved with VRML... (1)

Excors (807434) | more than 7 years ago | (#17317718)

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 Google SketchUp / Google Earth models. The list here [collada.org] has Ogre and Unreal Engine as supporting it too, and it's a "Standard part of the PS3 toolchain" (source (PDF) [scea.com] ) - so it is being used for real in games.

Re:Mentioning that you were involved with VRML... (1)

Assmasher (456699) | more than 7 years ago | (#17318778)

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 produce assets in your own file format (Granny3D is an excellent example of this.)

Re:Mentioning that you were involved with VRML... (0)

Anonymous Coward | more than 7 years ago | (#17319146)

Maybe he was referring to compressed and/or encrypted XML.

Why in flying fuck would he be referring to encryption? Or did you throw that in there to sound smart?

If Collada is .... (3, Funny)

j-min (1011011) | more than 7 years ago | (#17318172)

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 (1)

monopole (44023) | more than 7 years ago | (#17318346)

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.

Save some money by buying the book at Amazon.com! (0)

Anonymous Coward | more than 7 years ago | (#17318380)

Save yourself some money by buying the book here: Collada [amazon.com] .

How's the state of Collada tools? (0)

Anonymous Coward | more than 7 years ago | (#17318424)

I've checked the "Post Anonymously" buttton since I'm not sure whether I feel comfortable associating my real name (and my company's) with some of the issues that I discovered when I last looked at Collada, but...

I'm involved in a company that's building 3d software tools for high end productions. Obviously, exporting from Maya is a big deal, but dealing with Maya's internal structures excited none of us. So we decided to take a look at Collada as our intermediate file format, because if that carried all of the information we needed for people to build and rig models before they got pushed into our part of the pipeline, then supporting it rather than supporting Maya directly would make us good citizens, and possibly help us deal with other tools more easily.

We started by trying to import some simple models out of, and then back into, Maya. No deal. Geometry collapsed or in the wrong places. Zero rigging information. Our rudimentary quick hacks got more data out of Maya.

What we eventually came to was that the current state of the art of Collada tools wasn't even up to the level of just dealing with exported .obj meshes from Maya.

I should probably get and read the book anyway, but does the book address the issues of adoption? That nobody's going to be writing tools to use this stuff until it can manage not just geometry (which it's failing at right now), but rigging, and that the tools we can publicly find seem to be missing a lot of these features right now?

Because I'd really love this to be a viable option, it'd save me a whole lot of writing silly conversion code, but right now I can look to RIB for output, and .OBJs for input, and we'll have to do the rigging from a Maya plug-in augmented by hand, and I don't see how another basic scene description language that's not there yet is going to help this situation.

Re:How's the state of Collada tools? (0)

Anonymous Coward | more than 7 years ago | (#17318962)

nobody's going to be writing tools to use this stuff until it can manage not just geometry (which it's failing at right now), but rigging, and that the tools we can publicly find seem to be missing a lot of these features right now?

I've only played around with COLLADA for a few days, but with ColladaMax (which I expect is very similar to ColladaMaya, being based on the same code on the XML side) I haven't had any problems with exporting Physique / Character Studio models. It's not so good when importing back into Max, but I believe that's by design (rather than bugs) - the format is (intentionally) lossy, converting animation curves into a series of keyframes and forgetting about Biped objects and not storing bones that don't influence anything, because otherwise it'd be impossible for a tool to do anything without reimplementing each modelling program's internals and it would defeat the point of using a standardised format. Since I'd have to do that lossy conversion in any case to get the data in a format which the game can understand, and I only ever need to export from the modelling program and not import anything back, it's worked well for me. Were you using it that way but still finding problems? (And was it recently? COLLADA does seem to have done a lot of its growing very recently, and I expect the situation was quite a bit worse a year ago.)

(It's nice that ColladaMa(x|ya) are open source, and COLLADA allows nonstandard extensions, so at least it's technically possible to support extra features of the modelling program - I don't know at what point it'd be better to give up and use a different file format, though.)

Re:How's the state of Collada tools? (0)

Anonymous Coward | more than 7 years ago | (#17319336)

My experiences were early summer of 2006. We simply took a couple of (in the words of the people who gave them to us) "fairly simple" Maya models that had "basic" (again, the words of the Maya jocks, they weren't trying to do Osipa controls or anything) rigging, exported them and re-imported them using ColladaMaya.

The level of what we got back (and what actually made it into the Collada file, on further inspection) was very much at a "we should have just used RIB" level. There are good parsers out there for RIB, the Collada export failed miserably at geometry that works just fine in assorted RIB streams, and there wasn't any credible attempt at handling rigging.

Scene description is a solved problem, and all of the solutions to it are pretty robust. Character description is much harder, but Collada has a long way to go before it gets to solving the problems that everyone else has long progressed past.

Already in popular use (0)

Anonymous Coward | more than 7 years ago | (#17318552)

Applications include Maya (using ColladaMaya), 3D Studio Max (using ColladaMax), Softimage XSI, and Blender. Game engines, such as Unreal engine and the C4 Engine, have also adopted this format.

Source: Wikipedia [wikipedia.org]

COLLADA Physics (1)

erwincoumans (865613) | more than 7 years ago | (#17319074)

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 (1)

ALoopingIcon (992589) | more than 7 years ago | (#17320418)

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? (2, Interesting)

mrobin604 (70201) | more than 7 years ago | (#17320636)

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 slower than they needed to be. Most time was spent, yes, loading and parsing ASCII.

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. This becomes very important when you have game levels with millions of vertices in them.

ASCII format data is great for human readability, but if you want quick iterative development on 3D assets, it is NOT the way to go for production tools. String parsing is very expensive for a variety of reasons. I know you can speed it up with hashing and tricks, but still it's never going to be as fast as a binary format, especially not one that can be loaded into memory and ready to work on with just a few pointer fixups. If you want human readability for debugging, have your tools generate some good log files when a verbose flag is passed in.

Re:XML is the best way to store data? (1)

Excors (807434) | more than 7 years ago | (#17321056)

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:

<source id="Sphere01-mesh-positions">
<float_array id="Sphere01-mesh-positions-array" count="78">0 0 1.000000 0 0.707107 0.707107 -0.500000 0.500000 0.707107 -0.707107 0 0.707107 -0.500000 -0.500000 0.707107 0 -0.707107 0.707107 0.500000 -0.500000 0.707107 0.707107 0.000000 0.707107 0.500000 0.500000 0.707107 0 1.000000 0 -0.707107 0.707107 0 -1.000000 0 0 -0.707107 -0.707107 0 0.000000 -1.000000 0 0.707107 -0.707107 0 1.000000 0.000000 0 0.707107 0.707107 0 0 0.707107 -0.707107 -0.500000 0.500000 -0.707107 -0.707107 0 -0.707107 -0.500000 -0.500000 -0.707107 0 -0.707107 -0.707107 0.500000 -0.500000 -0.707107 0.707107 0.000000 -0.707107 0.500000 0.500000 -0.707107 0 0 -1.000000</float_array>
<technique_common>
<accessor source="#Sphere01-mesh-positions-array" count="26" stride="3">
<param name="X" type="float"/>
<param name="Y" type="float"/>
<param name="Z" type="float"/>
</accessor>
</technique_common>
</source>

That list of numbers increases in size as the mesh gets more complex, but the XML is only an additive constant overhead per object. Storing numbers as strings is a constant factor, but it's not too horrendous - that example uses 588 bytes for 78 numbers, which is 7.5 bytes per number, and it'd be more like 9.5 bytes without the easily compressed 0s, so it's only about twice as much space as storing 32-bit floats (with about the same precision), which isn't quite "balloon[ing] amazingly" in size.

But it does hurt more in terms of loading time. With a 2.5MB 25K-poly skinned mesh [not a sensible mesh - I just tessellated a small one], it takes me about 200msec to parse the XML (using FCollada) and 150ms to process all the data (converting it into the game's binary format, which is actually 4MB of output but should be a third of that once I stop doing it so inefficiently), and I expect it could be quite a bit faster if it didn't have to parse XML. But our game engine only does that conversion once, and caches the binary version so it's much faster when you load the game a second time after modifying some data. That caching does require a bit more work, but it avoids the issue of slowly loading hundreds of megabytes of XML every time you start the program up, while still letting people export COLLADA files and have the game pick it up automatically - it seems to work well in practice at keeping the loading times sensible.

(The only real reason we're using COLLADA at all is that it's easier than writing our own exporter, particularly since we want to support Blender (to a limited extent) as well as 3ds Max - the fact that it's XML doesn't really matter, but if being XML has helped it gain some interoperability between tools then it seems to be worthwhile.)

Re:XML is the best way to store data? (1)

kellererik (307956) | more than 7 years ago | (#17322574)

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 disclaimer: no coffee yet

Re:XML is the best way to store data? (1)

Excors (807434) | more than 7 years ago | (#17323892)

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 and caches any changed files at load-time (so there's still the benefit of loading faster, all but the first time). If the converter is changed and every file has to be reprocessed, it'll take longer for each person when they next load the game, but it's still much quicker than having to download the result of a batch conversion process, and it still all happens transparently with no user intervention. It also lets the artists export a file and see it in the game almost immediately, with no manual steps and without us having to spend time on our own modelling program plugins. I expect it would be different if we could build all the data on one machine and send it over a LAN for everyone to load, and if we could afford development of better-integrated art tools, but this way seems to be the best we've found for our situation.

(When the game is eventually released it'll just have the already-converted fast binary files, so the COLLADA loading time and size are only relevant during development.)

Re:XML is the best way to store data? (1)

kellererik (307956) | more than 7 years ago | (#17324302)

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:XML is the best way to store data? (1)

mrobin604 (70201) | more than 7 years ago | (#17327834)

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 for processing data through a series of closely linked tools, it makes more sense to convert to a faster intermediate format so you don't get eaten up loading and writing files (I'm assuming a tool chain of specialized tools linked by scripts here, if it's a monolithic converter then again it doesn't matter).

Oh, and of course you'd be converting to binary for a runtime format, using XML for that is just crazy talk ;)

Re:XML is the best way to store data? (0)

Anonymous Coward | more than 7 years ago | (#17321412)

As for doing things faster, sure you can go about using proprietary modeling/rendering formats and yes - those programs will handle them faster and more efficiently.

I think the intent is to use it as an exchange medium. This can be useful for instances where there are no controls over the full content creation pipeline, as it is intended to lessen or eliminate compatability issues assosicated with proprietary formats.

As for ASCII and text usage, it isn't anything new to 3D file formats. Try opening an old .obj file in Notepad sometime. If there's something novel about Collada, it's probably putting the rigging, material, and other non-geometry info all in the same container. Doing this with XML probably isn't a bad idea, because then you could add other properties (production stamps? copyright hashes? emitters? who knows?) to a model without it totally confusing things for different programs and/or pipelines. Depending on what is being done, applications would simply ignore or strip out the data types they don't deal with.

COLLADA (1)

*BBC*PipTigger (160189) | more than 7 years ago | (#17321486)

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 necessarily has overhead and markup that would be assumed and invisible in any reasonable binary format but the benefits have seemed to outweigh the downsides. Just about every programming and scripting language available today has mature XML parsers which means that it can be increasingly easy to write conditioners as part of any asset pipeline in the future. Conditioners might pre-process surface normals or tessellate curves or tri-strip meshes according to particular constraints in preparation for certain platforms. Such tools can make for an incredibly modular pipeline comprised of highly specialized operations in a similar fashion to the Unix Philosophy of piping and filtering standard I/O.

The specification was designed to encompass the major needs of professional game developers and to leave plenty of room for extension both in future iterations of the standard itself and within each instance document according to each project's needs.

Some trade-offs have of course been made. Most DCC-specific construction histories were not represented last time I looked and efficiency can always improve... but the project had many ambitious goals and I think it has accomplished a noteworthy degree of success. The HTTP://Khronos.Org Group has adopted the standard (alongside OpenGL|ES and others). Sony has been promoting the standard through the PlayStation Developer's Network with each SDK and had sessions at their PS3 Developer's Day gathering early this year to introduce lots of "in the trenches" game programmers to the technology. I think increasing numbers of game studios will be adopting COLLADA for at least some portion of their art asset pipeline since the momentum of increasingly interoperable construction, viewing, and tuning tools is picking up.

Of course the standard can be useful to "amateur" game developers too... and we're likely to see repositories of both free and commercial art resources grow around the standard to better facilitate reuse and outsourcing of that work. It can even streamline parametric asset construction in the future.

COLLADA is an important standard for game development today and is the best candidate to become a foundational piece of any future truly Stephensonian Metaverse. Even HTTP://SecondLife.Com would be radically different if it supported import and export of COLLADA data. Arnaud and Barnes are brilliant guys who've done a great job on the whole project and their book is probably going to be an invaluable resource to anyone who cares about the future of entertainment and communication.

I'm admittedly biased though.

Sincerely,
-Pip

How will this affect X3D? (1)

Peter Amstutz (501) | more than 7 years ago | (#17326126)

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" and storing list data in xml attributes) that probaly turns off some programmers. VRML/X3D has partially filled the gap as a common interchange format between modeling programs, but it doesn't work beyond static models (vertices/polygons/texture coordinates) If Collada can be an effective interchange format for animation, physics properties, etc, that's going to be a big win all around -- except maybe for X3D.

Re:How will this affect X3D? (1)

Tony Parisi (773636) | more than 7 years ago | (#17341692)

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 Consortium (the organization that develops the X3D specification) figured it wasn't worth the effort to push in that direction. Over the last few years we have seen attempts to build games and other entertainment applications with X3D. The results have been mixed thus far, but promising. My own company is building an online virtual world system with X3D and we find that the blend of features is just right for a web-based solution. Would I use our Flux engine to build a AAA console title today? No. But it wasn't designed for that. I think that X3D is ideal for deploying lightweight game and entertainment content over the web, especially if there is a need for it to be moddable or support mash-ups with other Web data like Google Maps, etc.

Thanks (1)

luther2.1k (61950) | more than 7 years ago | (#17326174)

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 refreshing to see such sensible focus: it's not being billed as a new XML format that's going to revolutionize 3D (3D!) on the web and allow us all to live in gibsonesque cyber fantasies of the future, it's a being billed much more soberly as a standard medium of data exchange between 3D apps, something that's sorely needed (as anyone who's tried to write tens of 3D file import/export filters and had to make compromises with each and every one will tell you).
One thing this is not is a web format. 3D files, expressed as XML (or other HR formats) that specify models by vertices and polygons (or tri-strips/fans/edge-breaker-if-you're-lucky) are always going to be unwieldy. It's a bit like HTML specifying images pixel by pixel by using tags: e.t.c. In other words, a bit verbose for most non-trivial cases and in any case unreadable.
Tim.

COLLADA Review Should Have Been Posted In Games./. (1)

*BBC*PipTigger (160189) | more than 7 years ago | (#17328900)

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

Save some money by buying the book at Amazon.com! (0)

Anonymous Coward | more than 7 years ago | (#17428242)

Save yourself some money by buying the book here: Collada [amazon.com] .
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?