🚀 go-pugleaf

In article <1992Aug20.122428.1193@ciit85.ciit.nrc.ca>, Dick Jackson <Dick_Jackson@qm.ibd.nrc.ca> writes:
|> Hello, seasoned Explorers:
|> 
|> I may be missing something obvious, but here's what I'm trying to do:
|> 
|> First, the rationale:
|> It seems easy enough to turn a 2D Lattice of values into a 3D surface,
|> by putting the same Lattice into the Function and Displacement of a
|> DisplaceLat module.  (fine example: korea.z)
|> 
|> I have a 1D Lattice of values (intensity values of a spectrum), which
|> I want to see as a curve in space.  The Help for DisplaceLat would
|> make you think that it would have the same kind of effect as above,
|> pushing the line into the 2nd dimension.
|> 
|> To try this, I put two GenLats with 2D outputs into DisplaceLat ->
|> LatToGeom -> Render, and I got some great 3D surfaces (it helps to
|> put the Function lattice straight to Render too!).  But changing
|> the GenLats to 1D (with DataVec Length=1) gives me a straight line!
|> (DataVec Length of 2 can push the points NON-orthogonally into one
|> plane, but I want orthogonal displacement by scalar values!)
|> 
|> Help!  And thanks in advance!
|> 

You are right.  This is one of the things I hope to fix soon.
DisplaceLat tries hard to one of two functions, depending on its input
data.  As a result it (me, really) gets confused, doesn't do everything
right (as in your example), or keeps you from doing something useful.
DisplaceLat should be replaced with 2 modules:  HeightFieldLat (change coords
from N-D to N+M-D -- what you want), and OffsetLat (displace each point
non-orthogonally).

I hope to write those modules soon, but I can't make any promises about
when I acutally can.  I can send you the source to DisplaceLat with
a pointer about where I think you can patch the problem.  If so, reply
by email.

-- 

Robert Skinner
robert@sgi.com

	"The sendmail configuration file is one of those files that
	looks like someone beat their head on the keyboard. After
	working with it... I can see why!"

				-- Harry Skelton (harry@usrgrp)