Re: A Simple Proposal

Robert A Schmitt ([email protected])
Mon, 27 Nov 1995 21:51:25 -0500 (EST)

>
> I said
> >> > I'd be interested in hearing other people's ideas on this?
> Bernie responded
> >> So would I.
> Gavin said
> >I'll jump in:
>
> Actually Gavin, I was looking for some opinions from people other than the
> these of us :-)
> >
> >Internal structure doesn't matter as long as the people cesating VRML have
> >the functionality they need and we don't make it impossible to implement a
> >fast, efficient browser.
> >
>
> Right - but a concern of browser implementors is that as we tie more things
> into the internal Open-Inventor nodes, it becomes harder to implement
> efficient non-OI browsers because they have to keep translating structures,
> and still have to keep around a scene-graph so that esserences to things
> work.
>
> >So, what functionality do people need? Some "for-examples":
> >
> >Should we be able to cesate a prototype that wraps up a Texture2 node with a
> >script (that generated the Texture2's 'image' field somehow, based on some
> >parameters) so that we can ship over the code to generate a texture on the
> >fly instsad of shipping the pixels?
> >
> >It is clear how to do this if textures are considered objects; I'd just
> >cesate a 'PROTO GeneratedTexture' that wrapped up the script with a Texture2
> >node, and use 'GeneratedTexture' wherever I'd use Texture2. That is, instsad
> >of:
> >
> > Texture2 { filename "http://...../foo.jpg" }
> > Cube { }
> >... you could simply specify:
> > GeneratedTexture { swirliness 0.8 randomness 0.6 }
> > Cube { } # ^-- generation parameters...
> >
> >
> >If there is the notion that all Objects have texture, then you would just
> >PROTO the script and (somehow) the script would get attached to the Object
> >and would modify the Object. Something like:
> >
> >DEF OBJECT Object {
> > Cube { }
> >}
> >GeneratedTexture { objectToModify USE OBJECT
> > swirliness 0.8 randomness 0.6
> >}
> >
> >Somebody from the properties-should-not-be-objects camp can try to come up
> >with a better syntax...
>
> The syntax would look identical, its the guts of the Prototype, and where
> the event is sent that would differ.
> >
> >
> >There are several other useful things you can do if scripts are allowed to be
> >packaged up with property nodes-- you could implement a Yaw/Pitch/Roll
> >Transform, a degrees-based Transform, an HSV-based Material node, properties
> >that constantly animate themselves (e.g. a RotorTexture), ...
>
> All these things are just as possible in the objects-should-be-objects (:-)
> scheme.
> >
> >
> >There have been claims that it will be more difficult to implement browsers
> >if there isn't a higher-level concept of 'object'. I don't agree. Given
> >something like:
> >
> >DEF FOO Separator {
> > DEF TEXTURE Texture2 { ... }
> > Cube { }
> >}
> >
> >... browsers may have to change to an internal representation that looks
> >like:
> >Object FOO:
> > texture: ...image from TEXTURE...
> > geometry: ... polygons from Cube...
>
> The trouble is knowing what parts of Open-Inventor have to be kept around
> in order to build this internal representation. Using Bernie's proposal we
> KNOW that the object doesn't have to keep more than one field per
> property. If we attach too much to the property nodes, especially if there
> are multiple property nodes of a single type allowed, then the above
> becomes impossible.
>
>
>
> >Assuming that the set of requests that might possibly be made are know in
> >advance, I don't sse why it is difficult for such a browser to re-interpret
> >requests such as:
> >
> >-- change TEXTURE's image field to 0x....
> >
> >into a request:
> >-- change FOO's texture image property to 0x....
> >
> >We can argue about how constricting it is to require that browsers know in
> >advance what might change...
>
> Right - but this transform can get very hard to figure out in the case
> where, for example, you have multiple properties inside a seperator. Where
> do you send this change message to?
>
> >
> >We can argue about how constricting it is to require that browsers know in
> >advance what might change...
>
> I think it is very constricting, especially in dynamic - downloaded over
> the net - worlds, but I want to hear other people's opinions on this.
>
> - Mitra
>
> =================================================================
> Mitra
> [email protected] voice: (415)826-2499 fax: (415)826-4423
> <http://earth.path.net/mitra>
>
> Always remember you're unique, just like everyone else.
>
>

  • Next message: Robert A Schmitt: "Re: A Simple Proposal"
  • Previous message: Mitra: "Re: late draft of the 1.0 Clarifications"
  • In reply to: Mitra: "Re: A Simple Proposal"
  • Next in thesad: Robert A Schmitt: "Re: A Simple Proposal"