zingbat
|
 |
COLLADA
« on: September 24, 2005, 03:29:27 am » |
|
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.
|
|
|
Logged
|
|
|
|
Spasi
Full Member
 
Offline
Gender: 
Posts: 213
Molon Lave
|
 |
Re: COLLADA
« Reply #1 on: September 24, 2005, 03:40:01 am » |
|
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.
|
|
|
Logged
|
spasi zDimensions - Greece
|
|
|
arne
|
 |
Re: COLLADA
« Reply #2 on: September 24, 2005, 02:29:38 pm » |
|
Xith3d also got a collada loader (made by croft)
|
|
|
Logged
|
An optimist thinks this is the best possible world. A pessimist fears this is true.
|
|
|
zingbat
|
 |
Re: COLLADA
« Reply #3 on: September 26, 2005, 10:23:03 am » |
|
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.
|
|
|
Logged
|
|
|
|
cfmdobbie
|
 |
Re: COLLADA
« Reply #4 on: September 27, 2005, 02:16:32 am » |
|
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.
|
|
|
Logged
|
Hellomynameis Charlie Dobbie.
|
|
|
zingbat
|
 |
Re: COLLADA
« Reply #5 on: September 27, 2005, 08:24:13 am » |
|
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 ?
|
|
|
Logged
|
|
|
|
zingbat
|
 |
Re: COLLADA
« Reply #6 on: September 28, 2005, 04:07:43 pm » |
|
By the way, this looks interesting: http://www.w3.org/2003/09/xmlap/xml-binary-wg-charter.htmlA 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.
|
|
|
Logged
|
|
|
|
gregof
Full Member
 
Offline
Gender: 
Posts: 125
in code we trust
|
 |
Re: COLLADA
« Reply #7 on: September 29, 2005, 06:58:33 am » |
|
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
|
|
|
Logged
|
|
|
|
Tomas
Full Member
 
Offline
Posts: 173
Agency9
|
 |
Re: COLLADA
« Reply #8 on: September 29, 2005, 08:12:40 am » |
|
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
|
|
|
Logged
|
CTO Agency9
|
|
|
zingbat
|
 |
Re: COLLADA
« Reply #9 on: September 29, 2005, 02:42:47 pm » |
|
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.
|
|
|
Logged
|
|
|
|
anarchotron
Full Member
 
Offline
Gender: 
Posts: 114
...precious bodily fluids.
|
 |
Re: COLLADA
« Reply #10 on: September 29, 2005, 04:20:50 pm » |
|
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]
|
|
|
Logged
|
|
|
|
Riven
Full Member
 
Offline
Gender: 
Posts: 162
Explorererer
|
 |
Re: COLLADA
« Reply #11 on: September 30, 2005, 02:25:42 am » |
|
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 to tiny I removed the loading-bars in my game.
|
|
|
Logged
|
I object to discuss your private fields and methods!
|
|
|
anarchotron
Full Member
 
Offline
Gender: 
Posts: 114
...precious bodily fluids.
|
 |
Re: COLLADA
« Reply #12 on: September 30, 2005, 09:22:54 am » |
|
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.
|
|
|
Logged
|
|
|
|
Riven
Full Member
 
Offline
Gender: 
Posts: 162
Explorererer
|
 |
Re: COLLADA
« Reply #13 on: September 30, 2005, 01:01:15 pm » |
|
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.
|
|
|
Logged
|
I object to discuss your private fields and methods!
|
|
|
anarchotron
Full Member
 
Offline
Gender: 
Posts: 114
...precious bodily fluids.
|
 |
Re: COLLADA
« Reply #14 on: September 30, 2005, 01:09:18 pm » |
|
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
|
|
|
Logged
|
|
|
|
|