Subject: REND386 and movement?

From: [email-masked]
Date: Tue, 14 Apr 92 04:07:46 PDT

I praise the authors of REND386 for their superb program!
 It truly is an amazing peice of programming. However since they asked
for possible improvements I have an idea or two. Why not set the view
port to the origin and thus save a few mults? (If I remember correctly
it is a bit faster than moving the eye around.) Then instead of moving
the eye, move and rotate the objects. I would like to see each object
include it's own x,y,z rotation and x,y,z location in the view system.
Finally, the 3d clipping could  possibly be speeded up by setting the
eye to the origin. Correct me if I am wrong, but the 3d clipping will
not show any part of an object if some part of it has passed the view?
If this is so, then the clipping could be speeded up by just checking
for a negative z coordinate in an object, when the eye is set to the
origin. I am sorry if I have stated something that has already been
implemented, can be implemented with the next verson, or is just plain
stupid. I am just a lowly neophyte in the world of graphics and a new
owner of an IBM 486-33. (Zoom!) I have programmed some 3d code on a
68000 and would like to attempt these mods, if the authors don't want
to take them up. It apears like minor changes in the existing code to
me. Is there anyway to get the ASM source code for the REND386.LIB?

Thanks for the GREAT PROGRAM and your time.

---

From: [email-masked] (Lance Norskog)
Date: Wed, 15 Apr 92 00:07:40 PDT

The basic idea of VR is that you have sensors on someone's head
and move the viewpoint when they move their head.  Or that you
have a funky control mechanism hooked up to mouse movements.

Of course, this supposes you're using REND386 for VR.  I'm more
interested in using 3-D software to show complex information
landscapes, and after using other VR systems I get more and more
sure that the right way to do this is to have a set of predefined
vantage points and jump between them.  In movies, this is called
"cutting" instead of "panning".

In this paradigm, for each switch it's easy to set the viewpoint to 0
by giving all objects working XYZ coordinates relative to the
viewpoint, view angle, and rotation.  Viewpoint changes would be slow
but updating the scene might be faster.  Interesting...

Lance Norskog