Slashdot Mirror


Universal3D vs. Real Open Standards

viveka writes "Back in April, Slashdot reported the announcement of a Universal 3D File Format by Intel, Microsoft & others - to be "as open as MP3". Of course, that's not all that open. And this turns out to be the sneaky part. There is a real open standard already - X3D is ISO-ratified, royalty-free, and has multiple open source implementations. U3D is "going to be submitted to ISO" - one day - but right now they're talking to ECMA, which allows royalty-bearing patents. I found this article by Tony Parisi, co-chair of the X3D Working Group a fascinating insider's picture of the standards wars, along with insights into what it takes to release an online game, what really killed VRML, and why open standards do (and don't) matter. I mean, a royalty-bearing, pseudo-open universal 3D format from Intel and Microsoft? Sorry, guys. That trick doesn't work anymore ;)"

9 of 174 comments (clear)

  1. MP3 an Open Standard? I tthink not by MJOverkill · · Score: 5, Informative

    Remember, the MP3 standard is covered by patents owned by the Fraunhofer Institute and THOMSON, and they enforce their patents.

  2. This is going nowhere by Anonymous Coward · · Score: 2, Informative

    Here is stuff straight from their standards page:

    * Open source, so no licensing issues.
    * Has been officially incorporated within the MPEG-4 multimedia standard.
    * XML support makes it easy to expose 3D data to Web Services and distributed applications.
    * Compatible with the next generation of graphics files - e.g. Scalable Vector Graphics.
    * 3D objects can be manipulated in C or C++, as well as Java.

    Sure looks like everything VRML attempted to be an then some, guaranteed to be another crash and burn.

    "Hats off to WildTangent, the only one of the bunch who ever had a working business model". I know a few programmers that worked at WildTangent and I've play tested a few of their games. All of them were awful. The only people I've seen get realtime 3d right is Linden Lab, but that requires way too much infastructure.

  3. Re:Storing 3D vector data in a text file is braind by hopethishelps · · Score: 5, Informative
    Binary storage for 3D data makes a lot more sense since it is more compact and easier to parse

    A binary format for X3D is being defined. X3D supports multiple file encodings describing the same abstract model.

    But nowadays everything has got to be XML, even if it does not make any sense at all

    The XML encoding enables smooth integration with web services and cross-platform inter-application file and data transfer. An excellent idea, surely. See the X3D FAQ for more details.

  4. we already have standards by Anonymous Coward · · Score: 2, Informative

    X3D isn't a file format standard. It's some lame web 3D, lets resurrect VRML with a new name, specification.

    There are at least two opensource 3d file format standards that I know of developed by actual companies in the industry:

    http://www.softimage.com/products/pipeline/dotxsi/ v36/
    http://www.tweakfilms.com/main/gto.html

  5. Re:Too many hyperlinks by Archibald+Buttle · · Score: 3, Informative

    Too many links, and not one of them led to the 3D Industry Forum web site, which would have been useful since that's the group that's pushing U3D.

  6. Re:X3D is dead because it's an ISO standard by Mithrandir · · Score: 4, Informative

    The point that you have completely missed is that X3D is published to the website. Thus, it costs nothing (unlike most other ISO standards). The ISO spec got ratified just under a month ago and we have to go through one more round of editing (typos only) and we have to wait for ISO to formally publish it before it can be seen on the Web3d.org website. Prior to that, if you're a member of the consortium, you have access to it right now.

    On your second paragraph, that's a matter of opinion, of which I vehemently disagree with you. Many large organisations will not touch something unless it is an ISO standard. This is particularly true with both the European companies and the US military complex. To give you an idea of just how that works - as soon as we had the announcement in hand, we had 2 different branches of the US military formally announce that they require it as their one and only 3D interchange standard. By not going to ISO, we end up with the same problem as before - a psuedo standard with multiple incompatible implementations thereof. This solves the problem up front.

    Where Tony and I disagree is that X3D nor VRML has any use being a "Web" standard. Where VRML has been hugely successful is out in industry in places that don't care about the web. If you'd walked around the floor at any show where they do modelling and scanning data, you'll find every single scanner manufacturer uses VRML as their output file format. All the tools that take that raw data in and process it, use VRML etc etc. None of the success stories even use a web browser in the system. In the future, that is less and less likely to happen too. It's all about the back-end and integration work. X3D has been succeeding for a couple of years in there and will continue to succeed.

    --
    Life is complete only for brief intervals in between toys or projects -- John Dalton
  7. Re:X3D is dead because it's an ISO standard by Tony+Parisi · · Score: 2, Informative

    Hey Mihtrandir, >Where Tony and I disagree is that X3D nor VRML has any use being a "Web" standard. Where VRML has been hugely successful is out in industry in places that don't care about the web. Actually, I agree completely. Sorry if I gave any other impression. If you go re-read things you'll see that I took great care to characterize X3D, and what our movement is trying to do now, as about "real time" and "communication" not about Web. Web is like 10 to 20 percent of what this is about IMO. Tony

  8. Crazy by shplorb · · Score: 4, Informative

    There'll never be a universal standard for 3D because it's so application-specific. Some applications work with polygons and some work with parametric objects. It's the reason why only 3ds max can read .max files - objects and modifiers are represented parametrically, and only the plugins that generated them know how to create them.

    Then of course, the rendering applications like to have their own formatting of data for speed and efficiency issues. A DirectX game will have data stored in an optimal format that's different from say how a PS2 game will.

    Using XML is ridiculous, it's a terrible waste of space and introduces a large processing overhead before the data is ready for rendering. There's a reason games often store 3D data in the format the platform directly processes - so it can be read off disk and immediately blasted to the screen.

  9. Re:The issue isn't the zipped size by dtfinch · · Score: 3, Informative

    While I agree that xml is not well suited for holding massive amounts of data like that, and I might not do it myself, it's not as bad as it looks. A lot of good compression formats can be decompressed faster than they can be read off the disk on modern hardware, as a stream requiring a fixed amount of data. Additionally, many good xml parsers can also work on a stream, reducing memory requirements. And xml compresses very well. So the cost of xml may very often be a fixed amount of ram and little more disk space.

    The advantage is that it's easy to write tools for compressed xml based formats. No binary specs to learn. Just decompress the xml, look at it, and you're ready to go. OpenOffice uses a zip compressed xml format and produces files typically 1/10th the size of Microsoft's binary Office formats. And anyone with an xml parser and a zip (de)compressor can jump into writing tools to read, modify, or create them. And getting into 3D, a lot of people like to make mods, and being able to read and modify the files without any special software will make it a lot easier.

    And nobody expects XML to replace PNG or OGG. They serve totally different purposes. And as compressed as they are, textures and other media tend to dwarf all other data, binary, bloated xml, or otherwise.