mjbWorld - VRML File Format - Forum Discussion Why stop at physics

By: Nobody/Anonymous - nobody
file Why stop at physics?  
2005-12-13 11:58

Hello. 
 
Been thinking about the idea of having physics nodes in the scene graph. (I'm not sure how others feel, but when I think of x3d I think of a single graph of nodes).  
 
The thing about physics is, it adds alot more state information to the graph such as current velocity and heading. The slipper slope is of course, if you're going to be including this type of state information in the graph, why not store other useful state information such as damage for instance?  
 
Let's say I want to have a different geometry rendered depending on how much damage an entity has sustained. Would you build a type of selector node in the tree that checks the value of the damage field and renders the correct path? 
 



By: Martin Baker - martinbakerProject Admin
file RE: Why stop at physics?  
2005-12-14 09:41

I see what you are getting at, I guess it depends how we see the purpose of the standard? I think an important part of it is to transfer information about a virtual world between offline editing and rendering tools and also realtime simulation tools. The scene graph already goes far beyond just representing the shape of an object to representing its behavior, I think this is important to find a way to specify the behavior of an object in the most general way possible. It seems to me that most users of x3d would be forced to specify behavior as Script nodes but that means that editing, rendering and simulation tools all have to understand that same scripting language and tools that would allow users to graphically define the behavior would have to decode the script. 
 
It seems to me that it is far more general to specify behavior in terms of states and the events that change the states. 
 
So what would be the objections to having state information to the graph: 
Runtime Efficiency? 
When the simulation is running it would seem far more efficient to hold state information in a big table rather than a scene graph. However, I think this is an implementation issue, x3d is a storage and interface standard, there is no reason why realtime simulation tools can't easily generate a table of state information from the scene graph. 
Physics related states like position, velocity, acceleration, force, etc. are different in that they change every frame, they are very difficult to implement (even using a script), and they can possibly apply to a large number of objects (including h-anim). Therefore there is a strong case for building them into the standard. 
 
Loss of Generality? 
If we build very specific states into the standard like: "collision damage" then the standard could become too specific and loose generality. I think that states should be user defined if possible. I think the standard has already introduced nodes which are too specific to military simulations such as, Distributed interactive simulation (DIS) components, 
http://www.web3d.org/x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification/Part01/components/dis.html 
 
> Would you build a type of selector node in the tree that checks the 
> value of the damage field and renders the correct path? 
 
I guess that there is already part of this as the Switch node already exists: 
http://www.web3d.org/x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification/Part01/components/group.html#Switch 
I would like to see more general state nodes so that the user can define their own state names and values. I would also like to see a "state transition table" node, this would allow the user to define how events change the state. 
 
Martin

By: Nobody/Anonymous - nobody
file RE: Why stop at physics?  
2006-01-06 08:06

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.




metadata block
see also:

 

Correspondence about this page

Book Shop - Further reading.

Where I can, I have put links to Amazon for books that are relevant to the subject, click on the appropriate country flag to get more details of the book or to buy it from them.

cover This book introduces 3D concepts, VRML, Java3D, MPEG4/BIFS, and X3D. It is a very good introduction to the theory, The writers have an in depth knowledge due to their involvement in the standards making. This is a good book to help you choose which 3D open standards to use and to give you a good insight into these standards. It is probably not for those who want a basic introduction to 3D or for these who want a step-by-step programming in 3D book.

cover Covers VRML 2 (but not the upcoming X3D standard). A good introduction to all VRML2 node types and how to build them.

Commercial Software Shop

Where I can, I have put links to Amazon for commercial software, not directly related to this site, but related to the subject being discussed, click on the appropriate country flag to get more details of the software or to buy it from them.

 

This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2017 Martin John Baker - All rights reserved - privacy policy.