Re: WWWInline; include non-VRML data?

Mike Roberts (miker@nashua.progress.COM)
Tue, 18 Oct 94 13:15:07 EDT


On Oct 17, 6:00pm, Gavin Bell wrote:

> What happens if a WWWButton that Embed's a URL is picked twice?
>
> Adding the same set of children again doesn't seem very useful; maybe
> it should become "dead" and ignore picks after the first one?

I don't think this is what you want to do in all situations, though I do think
that in most cases it will be. I have run across may educational apps in which
creating a number of objects for sorting, playing with, etc is exactly what is
required, with no clear limit on the number of objects which may be created in
some cases, and in others, a fixed limit on the # of objects.

Some form of system in which a number of objects interact with each other via
(2.0 :) ) scripted behaviors, for example, you might want to create any number
of shoaling fish .... is what I am thinking about here. Or there is the
currently available "childrens art" app which lets kids create scenes with
interacting dinosaurs, etc. Most fun.

So I guess I think there should be one form of linking behaviour which adds a
number of sets of children, then becomes dead - ie, it has a numeric limit on
the number of children sets to add to a scene before becomming dead. Perhaps we
have some form of shorthand for infinity I don't know about which would
parametrically allow you to add infinite copies (or perhaps just a huge number
would be fine ..) ??

> You want a (fairly simple) behavior. I think we should let VRML 2.0
> define mechansisms to let you get that behavior. For example, wire a
> button to the whichChild field of a Switch node to make some part of
> the scene appear (you can make it an arbitrary URL by making the
> Switch's child a WWWFile node!) when the button is pressed. The
> semantics are very clear-- part of the scene was hidden, and the user's
> action caused it to become visible, but it is still the same scene.

I don't have a problem with the semantics of adding objects to a scene
**locally**. It seems to be a conciderably more powerful mechanism than
hide/show; and one which would deal with user created replicated objects well.

-- Mike