Posted on: Today at 20:19
So you want people who know how to program in OpenGL/JOGL to build a player applet for you?
I don't know that I'd put it quite
that way ;^}
I'm trying to involve VR-community folks in the project, rather than trying to do the whole thing myself... there are lots of folks who have already worked through the OpenGL/JOGL learning curve(s) and could do a better and faster job than I.
what I am after in this stage of the xVRML Project is building a cross-platform tech-demo viewer *application* based on an xVRML display Component in turn based on JOGL. I programmed for a living for a long time, and I teach programming, but as far as VR goes I just want to make the s/w tech happen so I can do my creative work. I'll go through the learning curve myself if I need to, but I'd rather get someone who has already done so involved at this point. IMHO more community involvement means a better product and in a shorter time-span.
And by the way, what app will you use to create xVRML worlds?
one of the beauties of a Schema-based notational system is that *any* generic XML editor which is Schema-aware (and most of them are these days) can be used to construct valid and well-formed xwrls. one of the things which I wish to accomplish (longer term) is to "fold" a JOGL-based xVRML Component (from the viewer application) in with an xVRML-specific XML editor Component to result in a specialized editor. *and*, in the here-and-now, if you are experienced enough at creating VR objects and sets and scenes that you can visualize what you are working on, then simply a generic Schema-aware XML editor will do nicely right now (I've been using oXygen to create example and test xwrls).
In my opinion what caused vrml to fail was hardware lack of potential and low internet bandwidth. Even today not enough people has adsl to play a decent vrml world in realtime.
I think you point to a couple of different issues here, and I also disagree with you about "what caused vrml to fail"... let me address the hardware and bandwidth issues first
very cheap machines today (in the < $1000 range) are faster and better at graphics than the most expensive of desktop machines were when VRML started out (in the mid-90s), so I am not too concerned over the hardware issue. the demands for better/faster/cheaper (largely driven by gaming applications) will likely continue to drive increased hardware advances coupled with decreased relative prices.
"low internet bandwidth"
this is indeed still an issue. game providers have to deal with distribution of new geometry and media files, and are constantly bumping into this issue. some SGI folks (if I remember right) did some empirical experiments comparing binary format files and gzipped files back in the 90s, and they reported on the VRML list that there was no significant difference in time-to-view. plugging gzip support into a Java-based system is pretty much as painless as any other I/O, so i'm not too worried about this... or at least no more worried than any other geometry-and-media provider for any other purpose should be.
"not enough people has adsl to play a decent vrml world in realtime"
perhaps I'm missing or mis-understanding something here... "playing" *any* VR scene (not downloading the geometry and media, *playing*) is unlikely to be effected by bandwidth issues any more or less using this file format than using any other file format. the scenegraph being used is not directly effected by bandwidth issues. but like I said, maybe I am missing or mis-understanding your argument here, so please help me to better understand what you are saying.
"lack of potential"
I'm going to have to make some guesses about what you mean here, but I'll "give it a shot"...
I think the potential of VRML was damaged by the spec process, and not by anything intrinsic to the file format. when the spec process was openly conducted on the www-vrml list, changes were rapid and consensual (because of the presence of some very smart and experienced 3D and VR people on the list and a lot of argument) and adaptation was also quite rapid. when the spec process was moved off of "the list" and into the back rooms of the X3D consortium (lo those many years ago) VRML lost momentum and tech moved on.
I regret to admit that I was a part of this process as the Blaxxun representative to the "Contributors Group" in the late 90s. when the effort started, DTDs (shudder) were the tech to use. the wrangling has gone on for so many years now that DTDs have been largely supplanted by Schemas, and with good reason.
a well-wrought Schema is human-readable, not just machine-readable. this is a very big plus for encouraging artists to work with a file format. one of the plusses of VRML was that an artist (*not* a codehead, an artist) could learn to read (and thus learn from) and to create with minimal tools objects, sets, and scenes in VRML. one of the goals of the Schema-creation stage of the xVRML Project is to insure that humans can read and understand instance xwrls. the feedback I have been getting from artists is that xVRML is human-readable.
this project is not just
about gaming, although gaming would IMHO benefit greatly from a cross-platform and human-readable VR interchange format. this project is about the larger issue of "VR on the internetwork", and gaming is a *part* of that.
I hope that I have addressed most of your issues here. I think this is a useful conversation. if you feel moved to participate in the project, welcome. if you do not feel so moved, I hope you continue to think critically about and to comment on it. this sort of interchange is quite useful.