Slashdot Mirror

For clients as graphically primitive as SecondLife, this is a relatively straightforward task of publishing a simple texture & mesh specification. But if you want to push things to support more complex graphics and more efficient avatar and object systems, you quickly step deep into implementation specific issues that generally kill efficiency across implementations.

I worked in games tools and engines for almost 20 years, with years of art path work and a focus on avatars and interoperability, and frankly the more efficient you design your system, the harder it is to describe it in simplistic generic terms. Add vested interests and committees, and you are likely to get a repeat of VRML - one company railroads the process to accept their spec, which hobbles progress forever.

Shameless plug: I've also been working for over a decade on massively multiplayer vr & games over p2p, something that will come online this year as proprietary, but move to open source once our small group leverages our first mover advantages. Our website doesn't show it yet, but the underlying tech is at least a generation past anything on the market to date - imagine a superset of Sims2 avatars and active objects with coding interfaces in Python and C++, in-engine collaborative editing of the world, open art import paths, integrated CreativeCommons rights, content rating, audio chat, all built on military grade crypto w/ Byzantine robustness. And we're always looking for more help, need more veteran programmers and human animators. http://www.vscape.com/

I suggest IFF. I've been working on an open spec for 3d content based on XML as a hobby project since VRML dropped the ball, and at the same time working on a parallel IFF chunk hierarchy based spec.

This lets me have text XML when I need human readable, and lets me have quickly parsed binary data when I need that - best of both worlds, and trivial to translate between. From experimenting with all the ways to do this, I've found XML/IFF chunking to be a clean map...

An older version of the spec is at http://www.vscape.com/vml/index.html, if anyone wants an example of how this could work.

Post has been up long enough, slow topic, we'll see...
First is on desk, thats normal sized pen in front.
This is closeup of surface detail... Sorry for small pic size, these were taken w/ PDA...

Post has been up long enough, slow topic, we'll see...
First is on desk, thats normal sized pen in front.
This is closeup of surface detail... Sorry for small pic size, these were taken w/ PDA...

Long term, you're probably right -- the cost of steel, copper, aluminum for the transmission lines goes down. That'd be competing with the obvious pressure to move power generation closer to the users, which would be balanced out by capital cost and capacity limits -- you tell me what they are and we can make a guess where the breakeven would be. When I was thinking about it, it was with Bussard's notion of a "Farnsworth fusor" (see, eg, here, here, or here, or the Google search here.)

This leads to a notional reactor that's 5 meters across, and yields 10 gigaWatts (6600 Amps at about 1.5 megavolts DC, and be damned to Tesla!) using proton-boron fusion.

(Note: I'm not a physicist, and I'm not a power engineer, so don't come after me if you don't like these ideas.)

The whole thing is basically a big empty conductive sphere with some accessories, so it shouldn't cost more than about $1 million, so we're definitely in the neighborhood of pennies to mils per megawatt-hour. But it's almost an embarrassment of riches: how to you deal with a city of, say, 5000? A million bucks is a feasible investment for a city that size, but what do you do with the 9.75 gigawatts left over?

X3D is simply a mapping of the VRML language into XML. While this does buy you a good deal of cool XML features, like using XSL to completely remodel what/how your modeling, it doesn't address any of the core technical problems remaining to acheive large scale distributed 3d, and it in the name of backwards compatability it doesn't fix any of the remaining problems in the original standard that make VRML browsers "non-trivial" and hard to scale.

In order to acheive truly large scale distribtued 3d, it will take a different approach. X3D/VRML may be able to play a role as an import pathway for relatively static content or inefficiently scripted content, but little more.

[SHAMELESS_PLUG] For some time now I've been working to put the stuff I've been working on (that's raised tens of millions at startups like OnLive[Traveler]) into a public domain source base at www.vscape.com - It needs only a few more competent coders. I know there are other people who want to make this happen, we just need to work together. The technology now exists, the implementation and design decisions are challenging and fun. [/SHAMELESS_PLUG]

And yes, I meant "/.", not "./"... :)