Last updated on 11 December 1995.
Its useful for an Applet to be able to query the browser to be able to find out what version it is, and other useful information. This is done through a set of standard nodes with named fields that can be routed to Scripts, or read by behaviors through the API.
For example - if a Script needs to know the frameRate of a system then it could be connected by:
ROUTE _Self.frameRate -> Foo.frameIn
Alternatively, a script running asynchronously might query which type of browser it is running on via a call such as
GetNamedSFString("_Browser.name");
Issue: The API section on getting fields from the browser needs writing, its an open issue how to do this best.
The following nodes make up an initial set of nodes, its possible that other fields.
Provides access to the information about the particular browser being run, its all static.
DEF _Browser Browser {
#eventOut name "" # SFString READ name of the product e.g. "Worldview"
#eventOut version 0 # SFLong READ version e.g. 1.0
#eventOut langversion 1.0 # SFLong READ version of VRML supported
#eventOut machine # SFString READ machine name running on e.g. "PC"
#eventOut operatingsystem # SFString READ operating system running e.g. "Windows95"
}
Gavin/Rikk don't think that langversion, nodeTypes or extensions should be in here. And we don't think that we should encourage people to write scripts that depend on machine/operatingsystem, either, so want those to be left out.
Mitra: We need to give the author as much information as possible, so that they can write worlds that work well on different platforms, for example using RealAudio on a Windows box and .au on Unix.
Provides access to a collection of information about the running world. Typically these are currently in named info nodes. This node's contents only change when a new world is loaded, or something writes to the writable nodes.
DEF _World WorldInfo {
#eventOut environment # SFNode pointing to current environment node
#eventOut navigationHints # SFNode pointing to current NavigationHints
#eventOut,eventIn title # SFString contents of the title bar
#eventOut,eventIn sceneInf # SFString giving the sceneinfo for the current world
#eventOut,eventIn worldURL # SFString URL of world running
#eventOut enteredWorld # SFTime time started viewing this world
}
Gavin: there is no "current" environment node (there can be several in a
world).
Mitra: VRML1.1 describes Environment node as GLOBAL values, which I understand to mean there is only
one
Provides access to information about yourself, i.e. your camera position, this changes dynamically.
DEF _Self SelfInfo {
#eventOut,eventIn navigationMode # SFEnum current navigation mode
# (which might override that specified in navigationHints)
#eventOut,eventIn translationSpeed # SFLong translation speed
#eventOut,eventIn position # SFLong position of the camera
#eventOut,eventIn orientation # SFRotation orientation of the camera
#eventOut frameRate # SFLong number of frames per second
}
Gavin: allowing a direct connection from viewer position/orientation into a script will make worlds unscalable. Much better to use a ProximitySensor to limit the scope and keep worlds scalable and composable.
Mitra: Reading from a _Self node is going to make sense for scripts that need to continually monitor position - using these carelessly will of-course make worlds unscalable, but if a Script either reads the field via the API, or only adds a ROUTE to this event when it needs it, then its a powerfull tool.
Gavin: thinks the picked and frameRate fields are bad ideas because they will encourage sloppy, ill-behaved programming of virtual worlds.
Note that the avatar and neighbours nodes are placeholders, specified now to encourage experimentation.
This provides access to the current time
Issue: Several different times are available, do we need them all? They are included to support those cases where there is a simulation time which might run at a different speed from realTime.
_Time {
#eventOut realTime # SFTIME - the time asserted by the
# machine's clock.
# This might not be accurate, especially on low-end
# machines.
#eventOut,eventIn wallClock # SFTIME - in a simulation this is the time
# being simulated and in most circumstances this will be the
# same as realTime.
#eventOut elapsedTime # SFTIME - time since this simulation started,
# or the world was loaded. (This might not be useful)
}
Gavin: doesn't want to see this done as a pseudo-node. I'd rather just see one or more "get me the current time" calls in the Script API-- if you want a Script to be executed continuously over some period of time, then you must use a TimeSensor. That gives us scalability and composability in the time domain-- hooking up to a global source of time that is constantly ticking forever, we'll lose that.
Mitra: hooking up to time will be expensive, but reading the fields only when needed is usefull.