Subject: checking for next release

From: [email-masked]
Date: 01 Jul 92 19:06

First, the rotation of the segments may be the inverse of what is
expected.  I'm checking it out, but I need to know: how many
people have written software that would be adversely affected by
a change in segment rotation effects?  Basically, the rotations
alone would be the same, but in combination they'd act differently.
Right now, the rotation order is YXZ in world->camera format, but
this might be wrong for segment rotations.
          My vote would be to implement this regardless of the
          current impact.  The overriding reason is for the support of
          a user-intutive product.  Picking up and twisting/spinning
          objects are something that we learn at a very early age.
          And the ability to map this to the virtual world is
          critical.

On the same topic, the angle directions are probably not correct
for the left-handed coordinate system.  Comments?  Problems if
one or more of pan, tilt, and roll are negated in the next release?
          My vote would be to implement this.  I think that all
          pointer drivers and object manipulation tasks can figure out
          which way REND386 works and just compensate.  BUT, this is
          something that everyone who uses the library is going to
          comment about and it will haunt you to your grave.  I would
          vote for the right hand rule that goes (please ignore if
          this is too detailed) -- stick your right hand thumb in the
          positive direction of any axis and then your fingers curl in
          the positive orientation direction (but a left hand rule
          will work just as well, also -- but I don't know of anyone
          using the left hand).

A final structural note.  REND386 places objects directly in the world,
keeping object coordinates for use in segment repositioning.  As you
know, most other systems only keep object coordinates, then combine
the object position and view matrix to render the object.
Now, to do this in REND386 would slow the system by about 20%, and
would not decrease memory requirements to speak of.  It might allow
the reuse of object representations, but probably not their recoloring.

Can anyone think of an overriding reason to go to this method?  It would
be transparent to older software, of course.  But it would be a lot of
work, and slow the system, so I need some damn good reasons first.
          Dave, Can you list the pros and cons (from the point of
          the developer using the library) of the two options?  I'm
          not sure that of all the ramifications and I would hate to
          do something like vote for a 20% reduction in speed if this
          just boiled down to a documentation issue.
          Thanks, James

- Dave Stampe