Outstanding issues with VRML 2.0 

This covers outstanding issues with the final version of VRML2.0

Last updated by Mitra on 9^th December '96 

I've split this into three sections, covering: 

1. 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 
2. Clarification issues - places where the spec can be interpreted multiple ways. 
• WorldInfo needs clarification 
• SF to MF connectivity in Protos should be allowed 
3. Well I tried 
• Prototype limitations (Subclassing Script, Bindable nodes, using USE) 
4. Other issues
• Bernie Roehl   has a list of mostly Geometry related issues here.

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)