Check out this link http://www.theregister.co.uk/2004/04/21/intel_u3d/
30 companies are joining together to come up with a universal 3d file format.
This will hopefully mean the end of all those ‘loader’ questions we keep seeing on these boards. We’ll only need to support a single file format .u3d and implementation should be out later this year.
Andy.
[quote][…]the intention is to create a way of encoding 3D data as freely available as MP3[…]
[/quote]
As freely available as mp3… haha :-/
Seriously, the mp3 format isn’t free at all. If your application supports it you have to pay lot’s of money for it.
Doh! What a joke. We already have a universal file format, it’s called XML. The devil is in the detail.
Cas 
I think when they say “freely available” I think they’re referring to the fact that a high percentage of music on the web is MP3, not that MP3 is free to use in software.
Hopefully Cas the format they come up will be XML based, allowing for conversion of existing formats to this new format easily. I do think that representing an object such as those we’ll see in Doom 3 will result in huge file sizes though.
I like XML as a format, I work with it on a daily basis, I’d like to see a compressed XML become some form of standard to try and cut down on those file sizes, you can’t use ZIP since it has all those patent issuse like GIFs do/did (Yes you can compress it before transmission, but was it compressed with rar, lha or zip, you need a standard)
Andy.
Well, the LWJGL has an XML format now
Cas
I do think that representing an object such as those we’ll
see in Doom 3 will result in huge file sizes though.
The models in D3 are rather low poly. 1000-1500 polys that is (about the same amount as the hi poly versions of Q3s models). The details are added with bumpmapping.
However, the hi poly versions with 20-50k polys (wich were used to create the “low” poly versions + normal map) are a different thing.
See original posting/discussion at
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1082581875
HTTP solved this problem ages ago in a very simple manner, and it seems to have worked well with the test of time (c.f. Sun are now using it in 1.5 for the new JAR-packing format).
But…what’s the problem with ZIP? JAR’s use it, (don’t they???); has Sun paid a huge amount to be allowed to do this?
I may be completely wrong :-[, but IMHO, anything remotely universal/flexible will waste resources (memory, RAM, speed, etc).
Just take a look at the extendable and flexible NetBeans platform with its module architecture – the IDE takes a long time to load… :’(
[quote]I may be completely wrong :-[, but IMHO, anything remotely universal/flexible will waste resources (memory, RAM, speed, etc).
[/quote]
Ah; a C programmer, are you? Since OOP is designed to increase universality, re-use, flexibility, ease-of-modification, etc, you must obviously find that C++ and Java were both far too wasteful and slow for your needs…
Yes, if you take as your only example one of the lowest-quality applications written in the java language, and make an elementary logical error (“this is slow, and it is modular, therefore all modular things are slow” - this is an example of the classic “all men are socrates” logical proof), then it is perfectly reasonable to think that everything it does is inherently slow / buggy / etc.
NB: if anyone wants to defend NB, I’m not going to respond to highjacking the thread. IMO, it is very badly designed and implemented. The fact that it is being used to support a fallacious argument - modularity and flexibility are slow - would tend to support this.
Well, I’m not entirely happy with the speed (both startup and runtime) of the equally modular and clunky Eclipse, but the modular design makes sense in this context.
There’s a tradeoff between universality, modularism and reuse, and object oriented wank, which is a special kind of entropy that OOP introduces that prevents you getting a job done on time and in a manner that anyone else can understand.
Cas
Actually, OOP is not that bad, and neither is modularity, unless it is overdone. Without modules, one would have to program the whole app in one chunk, which would be kind of bummer, to say the least ;). Without classes, development would be relatively slow :(.
I guess what I’m trying to say is that
(1) I am not a C programmer
(2) modularity at the OOP level is fine – loading classes doesn’t annoy me too much, it’s an acceptable “waste” given the development time saved
No more comments on NB :-/
Regarding the original topic:
A u3d loader that supports all kinds of graphics would probably not be too efficient. Personally, I would prefer not to go the “all-encompassing .u3d file” route but rather do something like “.u3d with specialized, optimized loaders for specific kinds of models”.
[quote]Doh! What a joke. We already have a universal file format, it’s called XML. The devil is in the detail.
Cas
[/quote]
I think they are referring to streaming 3d worlds the way you can stream a video on fileplanet. I heard something about BIFS that can compress a 3d world with a gain of 1:10 compared with a zipped vrml file.