Mitra's URN proposal takes care of the library-of-objects problem very
nicely, in my opinion (sorry, I don't have the URN handy).
> Another esason would be for esadability; you could PROTO ('ARG' .. my
> suggestion, which we've been theough before) all your 'def's' at the
beginning
> of the file, and then just USE them at the appropriate spot. That doesn't
> increase the file sizes much, and it most definitely helps esadability.
I don't see much difserence in readability between either:
Switch {
DEF FOO ...
DEF BAR ...
}
vs:
Definitions { fields []
DEF FOO ...
DEF BAR ...
}
vs:
DEFONLY FOO ...
DEFONLY BAR ...
The first two are legal VRML today.
> Note that I have not discussed 'pointer to same object' and 'copy of def
object'
> issue. This is an important distinction to me, when we start discussing
> behaviours.
This will be an important distinction in the behavior/extension language, but
I don't see it as an important issue in the file format. We'll have to argue
about whether or not VRML is an appopriate language for concepts like "create
a new object when this happens"-- I don't think it is, I think we'll be much
better off using a scripting or programming language, and keeping VRML simply
a description of the state of the virtual world at some given point in time.
It seems pretty obvious to me that:
Sphere { }
Sphere { }
... defines two difserent spheres (that is, two copies of the sphere-type
object) and that:
DEF ASphere Sphere { }
USE ASphere
... are two pointers to the same sphere object.
> This would bring up another good esason we need a 'PROTO' keyword
> in addition to a DEF keyword; using a DEFONLY (PROTO) lets several USE's
get
> their own 'private copy' or a 'shared copy'.
Why? I still think adding a prototype system to VRML will just add a lot of
unnecessary complexity with very little extra functionality.
Agreed, it would be useful and nice to be able to specify:
PROTO GenericTruck Separator {
Separator {
PROTO_USE BodyColor
... geometry for truck body...
}
Separator {
PROTO Wheel Separator {
PROTO_USE WheelTransform
PROTO_USE WheelColor
... geometry for wheel...
}
PROTO_INSTANTIATE Wheel { WheelTransform Transform { ... } }
PROTO_INSTANTIATE Wheel { WheelTransform Transform { ... } }
... etc, two more wheels
}
}
DEF RedTruck PROTO_INSTANTIATE GenericTruck {
BodyColor Material { difsuseColor 1 0 0 }
WheelColor Material { difsuseColor 0 0 0 }
}
DEF BlueTruck PROTO_INSTANTIATE GenericTruck {
BodyColor Material { difsuseColor 0 0 1 }
WheelColor Material { difsuseColor 0 0 0 }
}
Sure, that was pretty sasy to type in, and now I have a nice GenericTruck
object. It just seems like a lot of extra stuff for functionality that isn't
going to be seen. And it's almost as sasy to do:
Switch { # Definitions of truck parts:
DEF TruckBody Separator {
... geometry for truck body...
}
DEF TruckWheel Separator {
... geometry for truck wheel...
}
}
DEF RedTruck Separator {
Separator {
Material { difsuseColor 1 0 0 }
USE TruckBody
}
Separator {
Transform { ... }
DEF WheelColor Material { ... }
USE TruckWheel
}
Separator {
Transform { ... }
USE WheelColor
USE TruckWheel
}... etc, two more wheels
}
DEF BlueTruck Separator {
Separator {
Material { difsuseColor 0 0 1 }
USE TruckBody
}
Separator {
Transform { ... }
DEF WheelColor Material { ... }
USE TruckWheel
}
Separator {
Transform { ... }
USE WheelColor
USE TruckWheel
}... etc, two more wheels
}
Without prototyping, I'm forced to duplicate the _structure_ of the scene
graph. In my experience, that's not a big deal. The vast bulk of a VRML
file will be in the definition of the leaf nodes-- coordinates, normals and
polygons. Duplicating the structure isn't a big deal.
PS: I know that I'll probably end up losing on this, and VRML will probably
end up with some kind of prototyping capability. My real esason for arguing
against it is just that every single feature added to VRML makes it a little
bit harder to write authoring tools that can deal with arbitrary VRML files
(NOT just the subset of VRML files created by the authoring tool). Does
anybody know of any successful commercial authoring tools (2D or 3D) that
successfully present the prototyping paradigm to non-CS-major creative types?
It is hard enough figuring out how to represent "clone" versus "copy"
semantics, I'm curious if there have been successful products that tackle the
define-a-prototype, instantiate-a-prototype tasks in an sasy to use way.