geomview

[munzner]

>% When I get around to having something to compile, where do I look to
>find out how nose was compiled? It seems difficult to locate
>compilation information. I particularly need to know what libraries to
>use, etc., and if there is makefile to look in that would be helpful.
>In particular I will be using some of the oogl libraries, such as
>libraries for manipulating 4x4 transformation matrices, and I want to
>know if I have to do anything special to load these libraries.

The makefiles are a bit nonobvious. There are top-level makefiles in
$geomroot/makefiles, which are included in Makefile and Makedefs in
every source directory. The Makefile in the nose directory doesn't do
anything except include some of these, to propogate compilation down
the tree. The "real" compilation takes place from the O.sgi
sudirectory Makefile. Here are its first few lines:

GEOM = ../../../..
include ${GEOM}/makefiles/Makedefs.global
include ../Makedefs
include ${GEOM}/makefiles/Makerules.obj

LIBS=-L${LIBDIR} -llisp -loogl -l3d -loogl

"lisp" is the Lisp library, "oogl" is utility routines, and "3d"
includes the matrix manipulation routines (which are in
$geomroot/src/lib/geometry/transform3). (If you are using
any of the geometry primitive libraries the dependencies are
extremeley nonobvious so we've defined an "ALLOOGLLIBS" macro in
$geomroot/makefiles/Makedefs.global:

# All possible OOGL libraries in the proper order, for convenience of
# application programs
ALLOOGLLIBS = -L${LIBDIR} -lcamera -lwindow \
           -lgeom -lquad -lpolylist -lvect -lbezier -lmesh -lvect \
           -linst -ltlist -llist -lbbox -lstub -lgeom \
           -llisp -lmg -lshade -loogl -l3d -lcolor

)


>% This question is maybe outside the realm of geomview. Are there any
>libraries for manipulating transformations of hyperbolic space? I could
>write some of this code myself, but if it exists it would be nice to use
>it. For instance, I have worked out the expression for 4x4 matrix
>representing the transformation of H^3 which takes any three points at
>infinity to any three other, but I have wondered if maybe this
>transformation exists already in some library.

See $geomroot/src/lib/geometry/transform3/tm3hyp.c for a few routines
that may be useful. (They're in the -l3d library referred to above.)

To forestall some confusion: 

Many of the transform routines have two flavors: Tm and Ctm. "Ctm"
concatenates the "answer" transform with the transform passed in,
while "Tm" just sets the transform passed in equal to the "answer".
(Here concatenated means pre-multiplied.)

You'll see a lot of source code for routines that have the prefix
"Tm3/Ctm3" but that are used elsewhere by calling a routine prefixed
"Tm/Ctm". Likewise, the source in the transform3 directory uses data
structures "Transform3" and "HPoint3" instead of "Transform" and
"Point". This is so that redefinition can take place behind the scenes
that is transparent to anyone who just uses Tm/Ctm/Transform/Point
syntax, which is what you should use.


>% I think I am going to just imitate what you do with the Lisp library
>in nose.c, but I have a few questions about the Lisp library. You wrote
>me earlier about how the function call ``p = PoolStreamTemp(...)'' sets
>up a pool for the lisp library to intercept input strings. Then nose.c
>goes into an infinite loop calling ``LEvalSexpr(p)''. Can you confirm or
>correct my guesses about how LEvalSexpr works?
> 
>First, LEvalSexpr seems to intercept an incoming string, although it is
>not clear how it detects the end of the string; does it look for the
>first carriage return? or newline?

It reads an entire parenthesized chunk (an s-expression, in computer
science jargon); i.e. it expects the first non-whitespace char to be
'(' and reads up to and including the matching ')'.
 
>Then it processes the string, using the user supplied function
>``Lpicked()'', which has been passed to the Lisp library in the
>incantation LDefun(). Is this all accurate so far?

The lisp interpreter parses the s-expression and evaluates it
as a lisp statement.  In the simple case of "nose", the only
defined function that it knows is "picked", defined by the LDefun()
call.  All input to nose is thus assumed to be of the form

	(picked ... )

which is the format of the string emitted by geomview when a pick
event happens.

>The first argument of LDefun is a string, which in nose.c is the string
>"picked". Nosing through lisp.c, I see that this argument is treated by
>the library as a name for the function. Do I have to know anything more
>than this? 

No.

>I haven't been able to find anywhere else where this string
>is used.
> 
>The main work of parsing the string seems to be done by Lpicked, which
>then passes the results of the parsing to ``handle_pick()'', to tell
>geomview what to do. So mainly what I have to do is to just copy
>verbatim the contents of Lpicked(), substituting the final call to
>handle_pick() with my own routine. Does this sound reasonable?

Very.

 
>% When nose sends stuff to geomview via the pipe, the first thing it
>does is to define the littlebox, then it turns on picking, then it sends
>the following command:
>(geometry "pick" { LIST } )
>What is the purpose of this command? I noticed that the next command is:
>(normalization "pick" none)
>Is the first command necessary for geomview to create the object "pick",
>so that the second command has something to operate on?

Yes. (geometry "pick" { LIST } ) is also used in the handle_pick
routine to temporarily get rid of the littlebox when nothing has been
picked (i.e.  draw nothing while saving the attributes (normalization
off) of the box instead of calling (delete "pick"), which
permanently gets rid of an object.


>% About scenes and picking. Suppose you have set up one camera looking
>at the world, and another camera looking at a scene which has been set
>up with the command
> 
>(scene  id GEOMETRY)
> 
>When geomview informs you of a pick, how does it distinguish between an
>object picked from the world and an object picked from the scene? My
>guess is that since objects all have their own names, and since geomview
>tells you the name of the object picked, geomview will let you pick from
>either the world or the scene, and then it is up to the user to look at
>the name reported by geomview, to discern where the picked object came
>from.

Correct.
	 
>% Something tells me this is asking too much, but: in geomeview, is it
>possible to drag an object, with intermediate positions of the object
>being picked? This is what trigrp does: trigrp allows the user to grab
>the intersection point of the colors in the fundamental domain, and drag
>that point, all the while sampling the intermediate positions of the
>point, and sending the relevant info to geomview to draw the tilings
>corresponding to the positions of the point. As you have told me, trigrp
>uses the GL libraries to do this. This concept of ``drag picking''
>definitely seems to be another step above ``click picking'', which is
>what geomview can do now.

Correct: geomview now only does click picking not drag picking. I
think drag picking would be pretty useful and so I'll try to add that
capability when time permits (i.e. not within days, maybe within
weeks, probably within months). 

Tamara