oogl, geomview, and more

[munzner]

>I have tons more questions that I am sending direct to you only
>because you have been so gracious and helpful with my previous
>questions.
> 
>() This could represent a hole in my knowledge of the C programming
>language, which I haven't been able to patch up. How do you read the
>following line of code from transform3.h, where Tm3Coord has
>previously been typedefed to be a float:
> 
>typedef Tm3Coord Transform3:4::4:;

In our version of transform3.h it's straightforward C:

typedef float Tm3Coord;
typedef Tm3Coord Transform3[4][4];

I'm somewhat mystified about how the brackets became colons in your
code. Is this the same in both $geomroot/include/transform3.h and
$geomroot/src/lib/geometry/transform3/transform3.h?


>() What's going on with the "read" command? In your letter, you
>referred to "handles" in the oogl.5 manual page, but I couldn't find
>any reference to handles.

	    The	":" construct allows references	to symbols, created with
	    "define".  A symbol's initial value	is a null object.
	    When a symbol is (re)defined, all references to it are
	    automatically changed; this	is a crucial part of the support for
	    interprocess communication.	 Some future version of	the documentation
	    should explain this	better...

Hmm. This is it in oogl.5 and indeed it never uses the world handle. I
guess that's one of those things that's in the code but not the
documentation (it's the name of the structures that make this kind of
thing possible). Like we admit, the documentation is overly sparse on
this stuff.

>As you suggested, I looked at the output of trigrp. In the output of
>trigrp, I noticed that the read command spits out something every time
>that you move the intersection point of the three regions in the
>fundamental domain, something like this:

>(read geometry { define fd { = OFF  .....

Trigrp also spits out the following reference to the symbol fd:

(geometry trigrp { = INST tlist < ./groups/g236.prj unit : fd })


>() What's going on with the "geometry" command? Does this command
>actually instruct geomview to insert the object into its world? Is
>that the difference between "read" and "geometry", that "geometry"
>puts the thing into the world, but "read" just changes the internal
>state of geomview without actually putting anything new into the
>world? The point seems to be that this can lead to side effects, if
>the "read" changes the definition of some object which is embedded in
>some geometry in the world. Is this accurate?

Yes, this is correct. "Geometry" actually puts something in the world,
while "read" has no direct effect on the world and is used only for
the side effect of updating a handle (embedded object). So if you've
never defined any handles, read does absolutely nothing. 

You could kind of think of "read/define" as setting a variable
declared by the ":" syntax. (The C declaration analogy breaks down
because it's perfectly fine to set the value and then reference it,
which would be backwards in C. (To reference and then set is also
fine.))

 
>() My current understanding of the trigrp module is that it uses the
>oogl libraries to display the fundamental domain, and allow the user
>to move the intersection point of the different colored regions. You
>mention in your letter that trigrp "handles raw GL events (like
>tracking the mouse) on its own". Could this have been done with the
>oogl libraries? Can you do picking with the oogl libraries? Evidently
>you can do picking in geomview, as is done in the grafitti module. Is
>the picking part of geomview alone, or is it written into the oogl
>libraries?

The short answer is "both".  There are indeed OOGL routines called
GeomPick and GeomMousePick and geomview routines like view_pick and
pickstring. I'm not going into more detail because I think the answer
to your last question will supercede this. (If not, I can go into more
detail.) 


>() The grafitti module brings up another question. I am guessing that
>grafitti works like this: a point is picked in the geomview world, and
>information about that point is passed to the grafitti module, which
>then passes back information about how to draw. Is this accurate? If
>so, what is the mechanism for geomview to pass picking information to
>the module?

Correct again. Nose is a better (simpler) example of this than
graffiti. Start it up inside of geomview when you've got one or more
objects already loaded. Click with the right mouse button in various
places.

Nose registers interest in hearing about pick information by the
command "(pick yes)". Then when a pick occurs in geomview a pick
string is sent to Nose. Nose uses this info to construct geometry
which it sends to geomview. It illustrates the granularity described
below: a yellow box for the point of intersection with a polygon, blue
boxes to mark an edge, and a purple box if a vertex was hit.  Nose
uses the lisp library to parse the pickstring. Nose uses world
coordinates, which makes it easy to put its little boxes in the right
place. I think you will want to use object coordinates, since you
really want to know which point on your coordinate plane was picked.
(In which case you would send "(pick yes object") over to geomview.)

Here's the relevant part of geomview.5

(pick	{no|yes} {world|object})
	"Pick yes" registers interest in picks: every pick event is
	written to the module's stdin. "Pick no" (the default) means
	pick information is not provided. The pick string format is:

	(picked "geomname" (ix iy iz) (vx vy vz) (e1x e1y e1z e2x e2y e2z))

	There are four levels of granularity in the pick structure:
	geom, intersection point, vertex, edge. The edge and vertex
	lists are nonempty only if the pick was close enough to an
	edge or vertex. 

	"{world|object}" is an optional keyword: the default is "world",
	which returns the pick string in world coordinates. "object" returns
	the string in the object coordinates of the picked object.

 
>() I have wondered whether trigrp could have been done with two
>separate geomview processes communicating with each other, or whether
>one geomview process can have two separate worlds communicating with
>each other. Are either of these possible? My guess is that the first
>is not possible, since there seems to be a fundamental asymmetry
>between geomview and a "module"; and the second is not possible,
>because geomview only has one world, albeit different possible
>cameras.

You're in luck: the latter (two separate worlds) *is* possible.
There's a (little-known) mechanism called a scene, which allows a
camera to point to something that's not in the world (or to be precise
even in the universe: there's geometry in the universe like the light
beams that are not in the world (thus they're known as "aliens").)
Anyway, the only reason trigrp doesn't use a scene is that we haven't
had time yet.

Scenes have not been thoroughly debugged yet, but I think enough is
there for you to get what you want: picking and drawing. (In a scene
the distinction between object and world coordinates is irrelevant. So
ignore the part about object coords above.)  From geomview.5:

(scene	id GEOMETRY)
	Make camera id look at GEOMETRY instead of at the universe.
	GEOMETRY is a string specifying a geom, as described in the
	OOGL Files Formats document.

For instance, "(scene c1 < foo.bar)".  At the moment scene will not
open a new camera window so you need to open an extra one "(new-camera
CoordPlane <optional camera specification>)" before you use this
command. Also, picking with scenes does not work on hierarchical
geometry i.e. no INSTS. So make your coordinate plane (a mesh would be
easiest) the right size to begin with. (An easy way to get a grid is
by drawing the mesh with edges on: you can even use graffiti to draw
on axes and such if you do the following: before starting up turn
normalization off (type "0N" from the keyboard). To save the object
type "(write bare <filename> g0)" into the command panel.)  We're in
the midst of changes that will, among other things, fix these two bugs
eventually. While we're on the subject of obscure but crucial bits of
knowledge, you can start up geomview with the '-c -' option lets you
type commands from the shell window you started it from (i.e.
"geomview -c - dodec.off"). 

If you do try to use scenes it's quite possible you'll find many a
bug, so feel even freer to write with questions. In spite of this I
think it's worth it to try it with scenes first since geomview command
language is much easier to deal with than event handling or learning
OOGL library calls.

Hope this helped more,

Tamara