Outstanding issues with VRML 2.0
This covers outstanding issues with the final version of VRML2.0
Last updated by Mitra on 9th
December '96
I've split this into three sections, covering:
- Problems with the Spec.
- Background doesn't explicitly support Movies
- TimeSensor - can't generate per-frame events.
- Visibility Sensors and Children
- Browser script interface can't be used to find bound nodes
- Execution Model ambiguities
- Grouping Nodes bounding boxes and changed children
- Clarification issues - places where the spec
can be interpreted multiple ways.
- WorldInfo needs clarification
- SF to MF connectivity in Protos should be allowed
- Well I tried
- Prototype limitations (Subclassing Script, Bindable nodes, using USE)
- Other issues
Problems with the spec.
Node Reference
- Background
does not support MPEG movies, while in theory they can be added by specifying
the URL, this won't work on all browsers, and there is no way to give the
time component of the Movie (when it starts). I had suggested using Nodes
(ImageTexture, MovieTexture, PixelTexture) but its too late now.
- TimeSensor
There is no way to ensure that you get one event per frame. It is expected
that MOST implementations will generate this, but its far from guarranteed.
Fallen on dead ears
- VisibilitySensor
and children
It does not appear to be possible to have a VisibilitySensor that monitors
whether a group of children are visible. There is no way to link the bounding
box of a VisibilitySensor with that of a Group (it isn't an eventOut of
the group).
Concepts
- Browser script interface does not allow finding what the currently
bound NavigationInfo, Background or Fog nodes are.
- Execution model ambiguity.
The execution model is bad for the case of fan-out followed by fan-in.
If S generates events with the same timestamp to A and B, and A and B both
generate events to C then Gavin's model says that C will output one and
only one event, which has to be generated by the first cascade (e.g. from
the event sent to A) there is no way that C can calculate its output based
on knowing the results of processing at A and B.
- Grouping Nodes bounding boxes and changing children
bboxsize and bboxcenter should be exposed fields, if a script changes the
children, it may need to change the bounding box.
Chris Fouts suggests that this should not expose changes if the bbox is
defined as the default (-1,-1,-1).
Gavin doesn't want to change it for efficiency reasons
I've proposed a possible way to meet efficiency, and changeable scene graph,
needs.
Clarification issues
- WorldInfo
should specify a format for the info string, and should probably include
a reference to the Dublin Core set of Meta-values, since if these occur
they should follow their conventions.
info [ "Author=mitra@mitra.biz", "Copyright=public" ] or
info [ "Author", "mitra@mitra.biz", "Copyright", "public" ]
- Prototypes
What are the rules regarding IS and SF to MF connectivity. For example
- is the following allowed
PROTO foo [ field SFString bestUrl ] {
Anchor {
url [
IS bestUrl,
"http://foo.com/defaulturl.wrl"
]
}
}
consensus is NO - but is MFString to SFString legal if its the only child? Again *NO* it will require a script. This still needs clarifying since many people read it the other way.
Well - I tried
This section covers things that I think are seriously wrong, but there
is no way to both fix them and meet the deadline. Unfortunately I agree
with Rikk that its better to be wrong, than not to get 2.0 out the door,
so I can't push to hard for these, but anyway …. For the record ….
- Prototype limitations
There are a number of limitations on Prototyping which potentially limit
extensability - therefore making it more likely we will need a VRML3.0.
specifically:
- It is not possible to USE something inside a Prototype, so for example
to avoid the multiplly USE-ed Viewpoint problem we can't go
Prototype Mouse [] {
Group {
children [
Viewpoint {},
USE MouseBody
]
}
}
- · It is not possible to create a new bindable node, maybe the
root class of "Bindable nodes" needs specifying, so it can be
extended.
- · It is not possible to subclass Script, so we have a Proto
that needs to be a Script and a Group, but has a set of events that could
be anything acceptable to the Script. We can't prototype this. (Think about
it, try writing the Prototype for the "Script" node)