COLLADA

[zingbat]

First nvidia is going to use this format for the next FXcomposer2 then sony announces this will be the format of choice for their games. I can smell there is something going on here with this scene format as a lot of 3d tool creators have also announced support for this.

COLLADA is mostly like xml being a text/xml encoding. It would be east to make a binary encoding for this and use it as an actual game 3d format.

[Spasi]

Yes, and almost all major DCC apps have COLLADA support already. I haven't investigated the full spec, but I generally find it a very positive thing for the graphics industry.

[arne]

Xith3d also got a collada loader (made by croft)

Games published by our own members! Check 'em out!

[zingbat]

I thinks you will find this interesting, if you don't know abiut it already:

https://sourceforge.net/projects/colladablender/

Im considering using xith3 for making the engine of my indie remake in java. Im working on a c++ engine on top of irrlicht but making a second engine on top of xith3d would be very usefull for comparision purposes.

Collada needs a binary encoding however. Reading it directly from xml is a pain in the ass.

[cfmdobbie]

I thinks you will find this interesting, if you don't know abiut it already:

https://sourceforge.net/projects/colladablender/

Fantastic!  Let's hope it gets into the core.

Collada needs a binary encoding however. Reading it directly from xml is a pain in the ass.

That's why you convert the models at compile-time into whatever format you like.

[zingbat]

That's why you convert the models at compile-time into whatever format you like.

Thats right. And that would be doing a collada binary encoding for me.

Why wasting time with yet another game scene format if it was much easier to create an encoding for a format i am already familiar with ?

[zingbat]

By the way, this looks interesting:

http://www.w3.org/2003/09/xmlap/xml-binary-wg-charter.html

A generic xml binary encoding would be great for game developers in particular. This would solve not only the problem colladas being text xml but the problem of all other data formats game developers plan to use in their games.

[gregof]

Collada needs a binary encoding however. Reading it directly from xml is a pain in the ass.

Hi
How is that so? reading from xml is not hard imho, and there are many tools available to make it easier, like for instance JAXB http://java.sun.com/webservices/jaxb/index.jsp
Agreed that xml might takes a little more memory and/or cpu when loading, but I for one gladly makes this tradeoff for the flexibility.

// Gregof

[Tomas]

Zip is extremly good at compressing text so its only during loading you get a memory peek,  so why bother with binary data  for files less than 100MB

Cheers
// Tomas

[zingbat]

Zip is extremly good at compressing text so its only during loading you get a memory peek,  so why bother with binary data  for files less than 100MB

Cheers
// Tomas

Someone i know made a benchmark comparing collada to a binary format madeby him and got these numbers:

collada size 6 times bigger
collada speed 10 times slower
loading and saving collada 8 times slower

Don't know how exact these numbers are.

If we compress collada files not only it will take more time to decompress the files but we still have to spend time parsing it with java xml apis. If we use a custom parser made with a tool like antlr for example it can take less time than using the java xml apis but i guess its still 2x or 4x slower than a binary format.

In a MMORPG or a game with a free movement world that is being constantly loaded from disk speed is critical. In a FPS  this is probably not very important but a map that takes 5 minutes loading is allways better than one that takes 40 minutes.

Games published by our own members! Check 'em out!

[anarchotron]

Parsing lots of large text based files at runtime will ruin your load times.  Long load times are one of my biggest pet peeves with games.  If your loading system isn't really really tight, it is _very_ easy for your load times to _very_ quickly get out of hand as your game progresses from prototype to completion.  Loading geometry data from ascii or raw xml is unacceptable from an end-user's usability standpoint.

[rant]
That being said the ImageIO.load() method for PNG is absolutely horrendous and is one of the slowest things in my loading chain right now.
[/rant]

[Riven]

I can imagine it's the slowest thing in your loading chain. Why don't you take it out then?

I convert all my images to either GREY, RGB or RGBA raw files. Then gz-zip it (or not) and you rougly have PNG-compression.

Giant textures (1024x1024 -> 4MB) then take like 100ms to load ingame. You can compress your files to DXTn before distributing, if you'd upload it to the vRAM.

Since I did this, my loading-times became so tiny I removed the loading-bars in my game.

[anarchotron]

What loader do you use for these formats?  Did you write your own?  Does DevIL handle all these?  I'd ideally use DDS files if a decent loader exists.

[Riven]

If you just put the *raw* files on your harddisk, you don't need a loader.

Just read the bytes and send them to the GPU with GL_UNSIGNED_BYTE.
Same goes for DXTn (n=1,3,5) which is natively supported by the GPU.

[anarchotron]

Ok thanks, I'll give that a shot.  I'm curious to see how the DXT formats handle mipmapping when feeding them directly to the card.

JW

[Riven]

Well, that doesn't work.

You have to mipmap your images, then convert to DXTn, store that on harddisk.
You'll only use 33% more space, which is acceptable.

[Aaron_Anderson]

Reading the spec Collada is not meant to be a delivery format but is suppose to be used for tool interopt

[zingbat]

Reading the spec Collada is not meant to be a delivery format but is suppose to be used for tool interopt

And thats because it's text/xml like we were discussing in the previous posts.