[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Rasters!
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Rasters!
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Sun, 11 Mar 2001 14:13:48 +0200
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3AAB68EC.C7122700@xxxxxx>; from b.fallenstein@xxxxxx on Sun, Mar 11, 2001 at 01:00:45PM +0100
- Mail-followup-to: "B. Fallenstein" <b.fallenstein@xxxxxx>, zzdev@xxxxxxxxxx
- References: <20010303125946.D19710@xxxxxxxxxxxxxx> <3AAB68EC.C7122700@xxxxxx>
On Sun, Mar 11, 2001 at 01:00:45PM +0100, B. Fallenstein wrote:
> Tuomas Lukka wrote:
> > Finally I'm coming to understand the mathemathical nature
> > of rasters and why they would be useful when using constraints
> > to describe the final view. Please take a look at the just committed
> > version (1.2 or greater) of Documentation/Manuscripts/Rasters/raster.tex.
> > The VanishingView could be described in about 10 lines of code...
> I think you get the tree view wrong. The "middle children" approach
> seems not to convey the real meaning to me-- which is: The center of the
> childrens' rank == the center of the parent cell + a gap constant.
> But the issues get more complex... like in this structure:
> / A1
> A - A2
> \ A3
> / B1
> / B2
> B - B3
> \ B4
> \ B5
> Here, the A node went up so as to be in the middle of the A1-A3 rank.
> Anyway, specifying this is much easier when you can address the center
> of a rank directly, instead of worrying about "middle children."
True. I wasn't satisfied with it when I wrote it. Will revise.
We should be treating the child rank as a whole somehow...