🚀 go-pugleaf

In article <1992Sep28.015732.20313@socrates.umd.edu> fletcher@socrates.umd.edu  
(Charles Fletcher) writes:
> A while back there was some discussion on rotating views of rib files
> with 3View. This seems to be file dependent. I haven't figured it out yet
> (I'm new to RenderMan and have not had time to t=really compare the files),
> but compare viewing of the examples given in  
/NeXTDeveloper/Examples/RenderMan,
> where mouse drag actions cause a translation; and the examples (like
> teapot or cdodec) from the PD posting (on purdue) ribs.tar.Z, where mouse
> drag actions cause a rotation (so you can actually turn them around
> and see the "back".)
> 
> Can anyone explain this before I rack my already beaten brain?
> 
Ok, well here goes my *attempt*. I'm close on this description, but I'm  
probably looking at some details from the wrong viewpoint. This 3D stuff is so  
confusing.

It seems like many others don't understand how to use 3View.app (I just  
recently figured it out myself) so I will describe some basics later in this  
post.

I'd like to start by saying that the examples from ribs.tar.Z on purdue are bad  
examples of rib files. Faceted surfaces don't even work on most of them. These  
rib files were 'translated' poorly from a very different format by an early  
version of an OOGL->RIB converter, and as such they don't make a lot of sense  
(as if ribs are readable anyway), and in fact contain lots of extraneous  
tokens. These will be replaced shortly by much better ribs (where faceted  
surfaces work!) with lots of cool shapes (fictional space station, human head,  
banana - all taken from various sources) though none of these will take full  
advantage of renderman in the realism sense :-(

A RIB from ribs.tar.Z will draw the geometry more or less at the origin of the  
world space - which, I *think*, is the point around which rotation in 3View.app  
occurs. This is where the NeXT example RIB files differ. They translate the  
geometry away from the origin of world space, so any rotation will cause the  
object to rotate at a given radius around the origin. The camera starts at the  
origin, so it appears the object is rotating about the camera (you can  
translate the camera around via the axis tool, but this won't change the center  
of rotation for the object).

The fact that the camera starts at the origin also explains why the RIBs from  
ribs.tar.Z always come up 'surrounding' the camera (thus requiring the camera  
to be translated). Before the world block, there is a translation:

    ConcatTransform [1 0 0 0 0 1 0 0 0 0 -1 0 0 0 0 1] 
    ConcatTransform [1 0 0 0 0 1 0 0 0 0 1 0 0 0 -3 1]

    (equivalent to "Translate 0 0 3" - ConcatTransform is how
     the OOGL->RIB utility sees a translation)

which moves the camera back from the origin of world space (where the geometry  
is drawn). This facilitates the photorealistic render - when these RIB files  
are rendered from the command line, they all comes out looking swell. However,  
QuickRenderman, when reading in a RIB file as a 'Clip Object', simply ignores  
anything outside of the world block (which is where the camera is supposed to  
get translated) and the camera and the object find themselves in the same  
place. To get around this (and to allow the example RIBs to be  
photorealistically rendered from the command line), the NeXT supplied RIB files  
simply translate the geometry away from the camera (and away from the world  
space origin & center of rotation in 3View.app).

Fortunately, a quick edit of the RIB files can move the geometry back to the  
world origin. After loading an edited RIB, just translate the camera back, and  
you can watch the geometry rotate more or less in place. The NeXT supplied RIB  
files have a Translate token shortly after the WorldBegin token. For instance,  
for Pixar.rib, we see:

##RenderMan RIB-Structure 1.0
 
 
WorldBegin
ConcatTransform [1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1]
Translate 0 10 0 
 
 
 
All you have to do is put a comment symbol '#' in front of that first Translate  
(or just delete the line with the Translate). Load it up in 3View.app, move the  
camera back, and rotate away. For Bag.rib, the Translate token follows  
immediately after the WorldBegin, etc. etc.


For those, who like me were clueless about 3View.app for so long:


A QUICK 3View.APP PRIMER, description of which may be wrong in places:

- The camera initializes at the world origin (I think it always looks down the  
negative Z axis).
- The Sphere tool provides the ability to rotate about the world origin -  
horizontal motion rotates about the y axis, vertical motion rotates about the x  
axis. Click-Dragging the handle rotates about the z axis.
- The Axis tool allows you to move the camera about world space. The X axis is  
always highlighted. Highlighting the Z axis allows for translation over the xz  
plane. Dragging mouse up moves camera in positive (renderman) Z direction,  
mouse down in neg Z direction, mouse right +X, mouse left -X. Highlighting the  
Y axis provides similar functionality for the xy plane. For ribs.tar.Z RIBs  
(and 'untranslated' NeXT examples RIBs), the camera will always have to be  
moved in the +Z direction.
- The rest of the tools are fairly self explanatory.

I know I didn't get this all right, but at least it's a step in the right  
direction.

-Scott Wisdom
The Geometry Center
wisdom@geom.umn.edu