Hi, I agree with Martin that the specification
should be a generalized modelling language and concentrate on
state information for object animation behaviour as a maximum
complexity.
I do understand that more 'game'
or simulation specific information would be desirable depending
on the application. This is what I spend most of my time actually
doing in VRML.
I treat VRML as a
graphic-engine and enhance behaviours of objects with
physics-related scripts and info. I also hold damage info in some
cases and use this to modify my models. I do all this using the
standard interface by creating my own PROTOs. As I see it, the
whole purpose of the PROTO interface is to allow application
specific extensions to the generalized standard
specification.
My PROTOs hold the extra info
for any given type of object or NPC in the simulation. They can
then have their own behaviour logic (steering, shooting, physics
etc.), they can also switch textures and shape info depending on
their current animation or damage state.
So,
the standard does allow for the type of information you want in
your scene graph but, rather than specify it in the general model
it is left open to the programmer to create their own nodes and
attributes via PROTOs.
It's horses for
courses. There are many game engines and progamming languages
available, all with their own capabilities and methods of doing
things. Although it might seem like a good idea to code this type
of stuff into a VRML engine, VRML wasn't actually intended to be
a real-time simulation platform but merely a way of browsing 3D
virtual worlds. With hindsight it is easy to suggest VRML should
have had XYZ capabilities but at the time those capabilities were
largely unknown and are to some extent still unforseen (not to
mention the sheer processing clout wasn't available on anything
but a supercomputer). Also, without a high degree of abstraction
and 'user-friendliness', your average Joe wouldn't know where to
start coding a scene graph with dozens of physics-related
behaviour logic attributes. As it stands, anyone intending to
build a 3D world in VRML still needs to understand the basics of
3D graphics and the VRML scripting language and syntax. I don't
think the original idea was for VRML to be a programmers-only
interface. It was meant to be something anyone with a little
common sense could get to grips with to produce an alternate 3D
version of a web page browsing experience.
For
those of us with more programming experience, the PROTO route is
there for us to really push the limits of what can be achieved in
a platform independant real-time rendering language. Having said
that, I often wonder why I don't simply develop my sims in Java
3D - it runs faster than most VRML browers, it looks better and I
have total control over all aspects of the logic. The simple
answer is laziness, I find it takes longer setting up models and
debugging code in Java than in VRML, plus I know that nearly
everyone with a web browser probably has a VRML plugin ready to
go, which can't be said of Java 3D. The happy compromise is to
code my PROTO behaviours in Java and use VRML as the 3D engine. |
