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 ;)"

7 of 174 comments (clear)

  1. How to fight this most effectively? by hopethishelps · · Score: 4, Interesting
    I mean, a royalty-bearing, pseudo-open universal 3D format from Intel and Microsoft? Sorry, guys. That trick doesn't work anymore.

    Unfortunately, with Microsoft's money and monopoly of the desktop, that trick might work. In fact it probably will work, unless some of us put together good ideas and good software using the open standard X3D before the bad guys get their bandwagon rolling.

    1. Re:How to fight this most effectively? by Mithrandir · · Score: 2, Interesting

      Or, do like us, and just not care about MS. We make all our money in applications other than dealing with microsoft. (FWIW, I'm the architect of Xj3D, one of the links provided in the article). Our money comes from developing custom applications using our toolkits that happen to support X3D, or providing complete solutions for devices like CAVES or other large-scale visualisation devices. We get paid to improve open source codebases, something which MS is not interested in.

      FWIW, 3DIF is just Shockwave3D. This is Intel's 4th attempt at trying to standardise it. They'll fail yet again. Look at the architecture of it, it sucks badly in that it does everything it can to prevent hardware graphics acceleration (ie Modifier Chains). Academically, it's nice, but for it's theoretical stated objectives, it just cannot work. It can't handle the millions of polygons required of CAD visualisation and rendering - either at the file format level or interactive frame rates. Just wait another year and watch it sink beneath the waves again. All it is is a couple of managers at Intel trying to save their arse on an already-failed project.

      --
      Life is complete only for brief intervals in between toys or projects -- John Dalton
  2. Re:This is going nowhere by Anonymous Coward · · Score: 1, Interesting

    H"Hats off to WildTangent, the only one of the bunch who ever had a working business model"

    that would be Wildtangent the spyware manufacturers ? yeah a buisness model based on user deception and datamining, nice ethical buisness model

    thats like saying "hats off to cometcursor and coolwebsearch for driving the development of toolbars,popups trojan horses and MSIE exploits"

  3. radians? by j1m+5n0w · · Score: 3, Interesting

    One of my gripes with vrml is that angles are specified in radians, and it looks like x3d is the same. Maybe it makes the transform math simpler, but Arghhh! Who in the world decided that radians were more intuitive to work with than degrees? Do they think no one will ever write 3d models by hand? I like to have "turn this a quarter turn" work out to a rational number.

    Maybe there's some way to set the default input mode to degrees, and someone will enlighten me.

    -jim

  4. Re:This is going nowhere by rsclient · · Score: 3, Interesting

    OK, I don't normally respond to "WildTangent is Spyware" -- among other reasons, because it's not my job. It's D----'s job. My job is employee number 10, Wild Tangent. I'm a programmer, specializing in whatever we need to fill our customer needs. And I'm irritated enough to want to write about three Wild Tangent related points, but I won't. I'm going to talk about the business of 3D.

    In the beginning, nobody quite knew what the 3D market was going to be. E-greeting cards that sing and dance? 3D Banner ads? Audio visualizers? Data visualization? And what was the business: who is going to buy? what do they buy? Does a web-3D company sell tools and make the "player" free? Or make the tools free, and the player free, but make a "technology license"? Or have the content cost money? Who pays to develop the content?

    Wild Tangent, like all of the 3D companies, tried a bunch of things. I've seen companies that made very, very simple tools that tried to fix the "3d is hard" problem (dead), and companies that made mini-movies to solve the "what sort of content" and "3d art is expensive" pro(dead) and companies that make tool sets (dead) and companies that make 3D community spaces (dead) and companies that make data visualizers (dead) and a lot of other things.

    Turns out, the right path is:
    - complex tools. Simple tools don't make for very interesting content, and people care a lot about interesting content
    - free player. Noone has made any real money by selling their player, even if it was a pain to develop. And believe me, they ARE a pain. I have the scars to prove it.
    - good content.

    One of the many wrong paths is the "datamining" path. Nobody really _cares_ about any of the data you could possibly collect from a user's machine (note: except for things that are grossly illegal like bank PIN numbers, of course). Suppose some web company could co-ordinate your DOOM-3 habbits, your email address, and the last three movies you saw: would it help LL Bean sell you slippers? Or GM sell you a Cadilac? Answer: no. And so they don't pay for it.

    And it's not just a pet theory, either. I get asked to add features to our products all the time; the features are never "let's get the user's email address" or "can you find out people's slipper sizes?". Instead I get questions like, "can we reduce the size of our 3d geometry" and "can we interface to the XYZ framework". And, by an enterprising-but-clueless sales person, can I make it work with PowerPoint because our 3D engine doesn't work on the Mac, but if it worked in PowerPoint it would because PowerPoint works on the Mac and it would be nice to work on the Mac.

    To summarize: Wild Tangent makes games. People buy games, and that makes us money. Games a re big business with enormous potential becoming very large and successful. Wild Tangent doesn't do yucky data mining because people don't pay for that and we wouldn't make money. Companies that do the sleazy things tend to be small and stay that way: it's just not a big business. And the Wild Tangent boss -- Alex St. John -- really, really wants to run a big company.

    --
    Want a sig like mine? Join ACM's SigSig today!
  5. The issue isn't the zipped size by Sycraft-fu · · Score: 3, Interesting

    The issue is the decompressed size. Fact is, you are going to have to decompress the data before you can parse it. Something like X3D is going to be HUGE compared to a binary 3D format. So, that leaves you one of three options when dealing with it:

    1) Decompress just as needed and render. Ok, but bzip2 requires a non-trivial amount of processor power to execute, and in any srot of high performance situation, you'll be doing a lot of decompression. You'll end up slowing way down wating on that.

    2) Decompress all objects for a scene to memory. That'll work but require a massive amount of memory comparitivley. Not going to find too many takers on an engine that needs a GB to deal with a scene that normal engines can handle in 128MB or less.

    3) Decompress all objects for a scene to disk. Better, but still going to use a lot more memory as the objects are loaded. Also will be slower, because of more disk access, and slower loading times for a scene because of the decompression process.

    Look, a text based markup works well for something like the web because the size of files is not significant compared to the result, and most of the data in the document is text to be displayed anyhow. The same is not true of graphics, espically not in any modren context like a game's 3D engine. You need to be able to get the data into memory fast, and it needs to be as small as possible and still be usable. With UT2004 occupying 6 CDs, and Doom 3 occupying 3 (and being faster when it's data is decompressed, though most of it is binary) you do not want a file format that is going to drasitcally increase the space requirements.

    Notice that there are good open formats that are binary, and for good reason, like PNG and OGG. With good documentation and standardization, they are easy to deal with in a program, yet they occupy little space in disk or memory and parse quickly. Try and reimplement a graphics format like OGG in XML and see what you get. It'll either be huge, or well compressed, necessitating a decompression step.

    It's a nice thought that all file be human readable, but it's just not realistic for deceant performance. After all, why not take it a step further, have all program work from source, have the comptuer interpret them on the fly. Well, there's a good reason that's not done for many programs. Even Java compiles to a bytecode, and doesn't run straight from source.

    What is easy to use for a human is not the same as what is easy to use for a computer.

  6. gzipped XML highly efficient for graphics storage by wombatmobile · · Score: 2, Interesting

    2D graphics data expressed as XML can be highly efficiently gzipped.

    You can see from these examples of Scalable Vector Graphics (SVG). The same documents in any other available 2D format are generally larger.

    And yet, when ungzipped, these SVG files are verbose XML text. You can see that by right-clicking when you view any of those examples with Adobe viewer and selecting View Source.

    SVG is a good example of how XML can be implemented efficiently over the wire (gzipped into efficient filesize) and yet accessed by the programmer at either end with no more than a text editor.