The xVRML Project [ http://xvrml.net/ ] has made pretty decent progress creating a Schema, Schema-docs, SAX2-oriented loader classes, javadocs, etc. The aim of the Project is to come up with an XML Schema to replace the old VRML97 for internet-based VR (insuring it is human-readable, valid, and produces human-readable instance documents), and then to build both a tech-demo standalone viewer and a set of browser plugins.

The next step for the Project is to build the viewer application(s), basing them on JOGL. Want to help? I want to avoid learning yet another new (to me) technology like OpenGL/JOGL... I prefer making new mistakes, rather than repeating old ones. Thus my desire to recruit Project members who already know OpenGL/JOGL.

"Xj3D is a project of the Web3D Consortium focussed [sic] on creating a toolkit for VRML97 and X3D content written completely in Java."

xVRML aims to *replace* VRML with an XML-based modelling language. The X3D Consortium has been trying for more than 6 years to come up with a DTD... so long that tech has passed them by. xVRML uses a Schema to specify the modelling language.

The Consortium's *basic* DTD is a couple of thousand lines long (and realistically you need the "additionals" DTD also to do serious work), and like most DTDs it is pretty much impossible for ordinary folks (for which, in this context, read "content creators") to read and make sense of. The Schema the X3D folks generated from their DTD is also many thousands of lines long, and pretty much unreadable by humans. The Consortium's Schema is pretty much an "afterthought", and doesn't even validate despite efforts by the VRML community to get them to revise it and make it a "first-class citizen".

The xVRML Schema is human (content creator) readable, pretty well documented (also unlike the Consortium's efforts), and only about 1000 lines long (*including* comments and annotation-node documentation). There is also already developed a package of SAX2-oriented java classes to load and represent and manipulate an instance world.

I've checked your URL and what I'm about to say doesn't appear to be covered.

It's a question that WILL be asked a lot, so I'd like an answer (even if I personally wouldn't ask it). I'm expecting you have a good answer, or I wouldn't mention it. I don't want to drag you down, I just want to know more about what you're hoping for.

So:

VRML sucked, why on earth do we want to do THAT again?

or, as some acquaintances of mine would put it:

VRML sucked, and ate 5 years of my life. I had fun, but why would I want to go THERE again? It was nothing more than a solution looking for a problem.

I myself wonder:

Why do you choose to re-use a brand (VRML) with such a terrible reputation amongst all but a tiny hardcore?

Basically, VRML had a lot of problems. IIRC updating the schema won't really do anything to fix the major ones; so, why bother? (I'm assuming there's some kind of good reason; even most of the academics / research staff I knew who worked on VRML eventually said it was pretty pointless).

> I've checked your URL and what I'm about to say > doesn't appear to be covered.>> It's a question that WILL be asked a lot, so I'd like an answer > (even if I personally wouldn't ask it). [snip]> I don't want to drag you down, I just want to know more about > what you're hoping for.

fair enough...

> as some acquaintances of mine would put it:>> VRML sucked, and ate 5 years of my life. I had fun, but why > would I want to go THERE again? It was nothing more than > a solution looking for a problem.

I don't think VRML itself really "sucked"...I think

a) the supporting tech (H/W and S/W) wasn't really "there" yet

and

b) the "stalled" state VRML fell into when the spec process was moved off of the VRML list soured a lot of people and contributed to tech passing it by

what am I after? a non-exclusive list might include:

- a modelling language which "makes sense" to artistically-oriented content creators who work with it and who try to read instances of worlds written in it (not codeheads, VR artists)

- a cross-platform and XML-based world format

- an easily extensible world format

- a world format as easy for the "average person" to learn and to use as is HTML

- a world format focusing on "VR on the Internet" in general, and not just on gaming

- a world format developed, maintained, and controlled by both codeheads and artists in an open process

So you want people who know how to program in OpenGL/JOGL to build a player applet for you ?

And by the way, what app will you use to create xVRML worlds ? 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.

Your idea looks good however but dont put much fait on Java xml capabilities. Vrml old text format is much more readable than xml and with a good grammar made with a tool like JavaCC or Bison you can load a vrml file much faster than using a xml encoding with the java api. An im talking about a gain of arraound 10x in speed.

Posted on: Today at 20:19So you want people who know how to program in OpenGL/JOGL to build a player applet for you?

wellI 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.

Quote

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).

Quote

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

"hardware"

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.

A xVRML player would not be very hard to do once you have apropriate knowledge. Unfortunatly what drove me to vrml was that i didnt have to know opengl or jogl to do some 3d scenes.

Just some days ago i decided to learn opengl/jogl combination. It will take some time and im planing on using a modeling language similar to xml and vrml but faster and more flexible. When that happens it wouldnt be too hard to build a grammar with JavaCC or Bison or even use Apache xml libraries to read xVRML. That would not invalidate people using a xml editor to edit their worlds.

Maybe you would better ask at the jogl forum. A good xVRML player and some content editors made with it would be nice to promote jogl as more than a games api.

I dont know if this helps but check out www.blender.org . That 3d app is free, its very good, it offres editing capabilities for all stages of production: modeling / skinning / lightning / animation / rendering / postproduction. And besides all this it can be scripted in python, all the manuals can be downloaded for free. Until you dont get some content applications made in xVRML it could be faster to do a python importer/exporter for xVRML in Blender.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org