|
|
Magic Mailing List |
|
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu) Date: Fri Oct 27 2000 - 19:17:22 EDT
Philippe O. Pouliquen writes: > Jeff W. Sondeen wrote: > > > >Rajit Manohar writes: > > > > > > If I understand this correctly, Tim's suggestion is to support > > > diagonal tiles of the form > > > > > > ------ > > > |`. | > > > | `. | > > > | `.| > > > ------ > > > > > > > but imagine that this is a 1000 by 1000 lambda tile, and we're > > checking 2 other tiles, one is 750,750 to 751,751 and the other is > > 753,753 to 754,754. they way tiling works, this check would have to > > consider tiles far away from it (namely the big one at 0,0) so you > > essentially lose the 1-d sorting that the corner stitching had been > > giving you. > > > > You must be talking about something that I don't quite follow. How > can there be a tile at ((750,750),(751,751)) and ((753,753),(754,754)) > if the big tile is at ((0,0),(1000,1000))? Tiles don't overlap on a > given plane. If you are talking about different planes, then the > problem already exists in the current manhattan geometry. yes, i was thinking about 2 planes, say a metal2 tile at 750,750 checking something about metal1 (and what i said about the tile at 753,753 was bogus), but you're right, that tile (at 750,750) has (almos) the same work to do in normal manhattan cases (that there might be a 1000x1000 metal1 tile at 0,0) (almost because with a normal tile it can just check the 'x' size of the tile (to see if it comes close to 750 but with a diagonal it has to consider angle). also whatever i said about 'negative slope' is totally bogus. sorry for the confusion. > > > certainly the design rules would be a problem, as they are specifed as > > "edge" rules (but would have to be interpreted as "paint" rules with > > appropriate (complicated) changes to how they check layout. > > > > /jeff > > I don't think that edge-based design rules need to be altered. > However, I'm not so sure about the "corner" portion of the basic magic > design rule. by the way, what would help a rule-writer (for the current manhattan version) is, referring to figure 9.1 on page 29 of the magic maintainer's manual #2, more control over exactly which corner type(s) the 'cornerTypes' refers to; my recollection is that better rules can be written if you can distinguish between the corner type just ouside B (of that figure) and the one just inside B (ie. the type of B). this may get to the heart of the DRC rule issue: even with Timothy's policy of treating the diagonal type as a normal type, (ie. if it's a poly/space diagonal tile, treat it as a poly tile), it's not clear to me what will fall out of the edge rules. > > Also, Timothy Edwards wrote: > > > > Naturally, I have not thoroughly worked this out, so anyone > > who sees insurmountable logical fallacies with my idea is > > welcome to point them out. > > > > One problem the I don't like is that if you start with a diagonal, and > partially paint a rectangle over it, the corners of the new rectangle > are not necessarily on the lambda grid anymore. I would hate to see > my diagonals move around because of this. Here is a simple example: > If you start with a 1x2 triangle, and paint a rectangle over half of > it, then the remaining triangle is 0.5x1. > > Now I had originally thought: no problem, lets store the coordinates > as integer fractions. But if you are dealing with large triangles, in > which the lengths of the sides are prime numbers (in lambda), things > can get horribly complicated real fast. > a good point. i think Tomothy's policy though would turn the diagonal into a normal tile, so your diagonal will disappear. but i would prefer to keep all coords as integers, just because of my dwindling brain cells. /jeff > Fortunately, if we just stick to 45 degree angles, the problem doesn't > occur. > > Philippe Pouliquen
|
|
|
|