--------------446B794B15FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Chris Marrin suggested that this mail would be related to this
working group about extending VRML.
-- _____________________________________________________________________________ Jean-Francis Balaguer Technology Manager 3D/VRML Artemedia Online SA e-mail: balaguer@artemedia.ch rue de Morges 24 tel: +41 21-706-2084 fax: +41 21-706-2071 1023 Crissier - Switzerland www: http://www.artemedia.ch/~balaguer/--------------446B794B15FB Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Received: from nurikabe.soft.arch.sony.co.jp (nurikabe.soft.arch.sony.co.jp [133.138.16.2]) by neuchatel.artemedia.ch (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04924 for <balaguer@neuchatel.artemedia.ch>; Fri, 25 Apr 1997 12:13:19 +0200 Received: (from daemon@localhost) by nurikabe.soft.arch.sony.co.jp (8.8.5/3.3Wb) id QAA03952 for vrml-java-deliver@soft.arch.sony.co.jp; Fri, 25 Apr 1997 16:55:13 +0900 (JST) Errors-To: vrml-java-admin@soft.arch.sony.co.jp Sender: vrml-java@soft.arch.sony.co.jp (VRML java binding Mailing List) References: <1.5.4.32.19970424184957.006fb4f4@mail.halcyon.com> <335FCB08.90A08F61@marrin.com> Message-ID: <33605DF9.41C6@artemedia.ch> Posted: Fri, 25 Apr 1997 09:32:09 +0200 From: Jean-Francis Balaguer <balaguer@artemedia.ch> Organization: Artemedia Online SA X-Mailer: Mozilla 3.01SC-SGI (X11; I; IRIX 6.3 IP32) MIME-Version: 1.0 To: chris@marrin.com CC: vrml-java@soft.arch.sony.co.jp, "J. Jeffrey Close" <close@halcyon.com>, justin@vlc.com.au Subject: [vrml-java:1493] Re: PROTOs, DEFs and optimized nodes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 25 Apr 97 16:55:12 +0900 Precedence: bulk Reply-To: vrml-java@soft.arch.sony.co.jp X-MLServer: nml.pl 1.1 X-Ml-Name: VRML java binding Mailing List X-Ml-Count: 1493
Chris Marrin wrote:
> There's another side to this. Today, you're doing traversals to "work > around" deficiencies in VRML, right? You want your object to sense its > environment, but VRML does not support this, so you're rigging your own > traversal to do it. The solution to look forward to is added VRML > capabilities that will let you do the things you want without having to > resort to traversals. Then we can have the best of both worlds: > autonomous behavior AND efficiency. > The problem is related that you cannot travel the graph up from a given node, so determining the material of your parent is not possible unless you start traversing the graph. It is related to some extent to multiple instances of node but this could be solved using sharing and delegation so that we have objects behaving as shared instances but having the ability to maintain local information related to their position in the graph, what is my parent, what is my global transformation....
Another direction is to put more intelligence in the routes. Suppose you want to express things like:
ROUTE the diffuse color of the material of my parent to the diffuse color of my material.
Currently you need to hardwire the DEF'd material of your parent with your DEF'd material. When anything changes in the graph, you need to rewire everything by hand. Painfull, boring, unpractical. Smarter routes could be expressed as:
ROUTE NODE.parent.material.diffuseColor TO NODE.material.diffuseColor
Now, what happen if the node is moved in the graph? Then the route is marked invalid and rewired automatically by the system. If one of the pointer variables is resolved to NULL then the route is put in wait mode until all of the pointer variables are resolved successfully.
This is standard techniques in research systems based on constraint propagation. You might want to take a look at Amulet (http://www.cs.cmu.edu/~amulet) or read about the VB2 system (http://www-venus.cern.ch/balaguer/publications.html)
In fact both of this system go a step further:
Amulet allows you to specify that a field is computed by a C++ function and all fields that are traversed to evaluate the function are automatically put in the dependency list of the field. The dependency list can change each time the function is re-evaluated. It is to some extent more related to the IS construct than to routes.
Think of specifying DEF SFNode same_as(SFNode self, int i) { return self.parent.children[i].geometry; }
Transform { children [ Shape { geometry Box {} } DEF NODE Shape { geometry IS same_as(self, 0); } ] }
Now if the geometry of the first shape is replaced to a sphere so is the second and this automatically. Of course a SFNode valued function is a perfect valid value for an exposedField.
Another approach is to put the function in the routes, having the function compute the location of a field variable rather than a value
DEF SFField same_as(SFNode self, int i) { return self.parent.children[i].geometry; }
ROUTE same_as(NODE, 0) TO NODE.geometry
The second option is a bit less natural for a programmer but more evolutionary with respect to VRML.
Now you can go a step further and have functions that compute functions that will evaluate a field's value.
With such constructs, the graph is becoming active, sensing what's happening around and reacting dynamically to changes, determining new dependencies that are specific to the current context. You gain a lot of expressivity and just have to declare a set of relationships that will run your world and let the system maintain it for you. Such systems can be built...
VRML is to some extent state-of-the-art with respect to the industry but it is still far behind some research systems. Let's not reinvent the will and learn from existing work.
Looking forward to hear your comments
-- _____________________________________________________________________________ Jean-Francis Balaguer Technology Manager 3D/VRML Artemedia Online SA e-mail: balaguer@artemedia.ch rue de Morges 24 tel: +41 21-706-2084 fax: +41 21-706-2071 1023 Crissier - Switzerland www: http://www.artemedia.ch/~balaguer/
--------------446B794B15FB--