I can see why you want to do this. I haven't thought this through all
the way but here goes:
- *IF* this is done we should limit the binding to a character, so
each character in a string can have different bindings, but multiple
bindings within a character would be *very* bad - if not nearly
impossible to implement.
- It would be nice if we all had access to some nice PD fonts that
were made up of polygons. I am willing to bet that most people
oly have access to fonts compromised of lines, and I bet those
people aren't in a rush to make polygons out of that data. All
of the nice polygon fonts I've seen are NOT in the PD, only the
really ugly ones are.
- The current treatment of AsciiText is nice, its simple. All it
says is that you have some ascii string to display, go ahead and
display it. So renderers can do it anyway they want. This is sort
of changing the rules in a very fundamental way.
> - Material binding on geometry nodes: why can't you do PER_FACE or
> PER_FACE_INDEXED binding of materials to a cone or cylinder node?
> Material binding on all of the geometry nodes should be consistent. My
> vote is that they all should be similar to how a cube is handled (i.e.
> allowing PER_PART, PER_PART_INDEXED, PER_FACE, or PER_FACE_INDEXED).
> Also a nit-pick, the description specifies "the first current material
> is used for the sides of the cone, ..." Change "Sides" to "side" as a
> cone only has a top and one side.
Chances are that the renderer has a fairly good idea what the side
of a cude is, and that is a face. Trouble with Cones and Cylinders
is that a face becomes *very* renderer specific. Users aren't going
to know what a "face" is to each renderer.
With VRML you say, give me a Cone, give me a Cylinder. When it comes
time to render the cone the renderer has many options, does it use
a tri-mesh? a quad-strip? does it use ...... ? So as you can see the
number of polygons generated by the renderer can vary, and doing a
PER_FACE mapping onto some polygon or a set of polygons generated by
the renderer can be a real pain-in-the-butt if not impossible.
It is easiest just to say that Cones and Cylinders don't have FACES,
only a side, top, and bottom. Otherwise, you start having to specify
all Cones and Cylinders by a list of polygons - and I don't think many
of us what to see that happening, its just tooo much of a pain, and
what we have now are two nice primitives. If you want to do a PER_FACE
mapping on Cones/Cyls just build the object by hand (by specifying the
faces individually). If you do the work for the renderer you will have
the control over the object needed to specify material binding at
whatever level you want.
> - Materials and lighting: I agree strongly with Eric Haines that the
> equations of the lighting model needs to be specified in the spec. This
> is important to be able to specify detailed lighting. I understand that
> many people want things that look roughly correct, but some or us to
> through great pains to make sure lighting and look are accurate. For
> instance, radiosity renderings go to great pains to calculate accurate
> lighting. If browsers implement lighting differently, the walkthrough
> will not accurately reflect the calculation.
I strongly disagree with this. You are starting to rape the renderer
by doing this. Renderers have built in lighting models that are
optimized for the renderer.
Also, this can become a real pain to deal with. Here are some
questions right off the bat:
- what does the equation you give me look like?
(BTW: the battles needed to be fought before this is agreed on
could last well into the end of the century:-) ).
- what does it suppose to mean to the different renderers?
- what guarantees do I have that as I try to solve it my
renderer doesn't crash (can users intentially give me bad equations?)
- what do I do if I simply can't deal with it at all?
I can see where a renderer is designed so that you can specify
lighting models for it, and it understands the equation, but making
a generalized model for all renderers is going to be hard.
> - Field changes: Similar to how state parameters can be passed into
> URLs from forms, browsers should be able to handle URLs specified in
> the form:
>
> url?field=value&field2=value2&...&fieldn=valuen
>
> When a browser sees a URL of this type it should change the values of
> the specified fields in the scene graph when the URL is read in. This
> gives a much easier way to perform limited interactivity. For instance
> clicking on a icon representing a camera could set the whichChild node
> of a switch to the proper camera.
I am having a hard time visualizing how the URL will look like, let along
how to construct one. Can you give us a real example? Lets say my scene
consists of a RED cube, and I want to change the color so it is BLUE
and translate it +100 units on the X direction. What would the URL
look like that would specify the changes?
Can't we not cheat and just wait to solve this problem once we are thinking
about dynamic VRML?
--------------------------------------------------------------------------------
Neophytos Iacovou Distributed Computing Services
University of Minnesota 100 Union St. SE
email: [email protected] Minneapolis, MN 55455 USA