Polygonal Thoughts

[mtnviewmark]

While I appreciate all the effort and creativity going on in the "how do I create an n-gon" threads... This comment by Chris:

Triangles ARE annoying, since it's pretty clear they have to be drawn with infinite parts.

Even worse: most curving shapes are in fact impossible. I'm pretty sure you can't draw any ellipse other than a circle, even with infinite replacements. I'd love to find out I'm wrong

triggered this thought:

Before we extend the CFDG grammar with these sorts of things, I'd like to learn more about the space that you can do with it. It seems very rich, very uncharted, and full of beautiful surprises.

[David Spitzley]

I don't think there's a rush to add new shapes, but you asked what we'd like, and you can see which way some of us are pointing. We'll see what else comes up in the next few days.

[chris]

One idea I toyed with when designing the language was the possibility of designing a terminal shape by vertices. That would be a pretty general solution and allow anything as one shape -- anything from an equilateral triangle to a rhombus to a letter of the alphabet.

For example, you could define something like this:

rule right_triangle {
POLYGON (0,0) (0,1) (1,0) {}
}

"polygon" would be a terminal symbol like square and circle, but it would take a list of points as vertices before the rules that followed it.

This of course doesn't violate the context-free rule, because those points are relative positions, with 1 referring to the 1 that would be a circle of the same diameter.

It would also fit right into GD because it can handle polygons by points like that, I think.

thoughts? From my perspective it's more appealing than getting into an ongoing shape-adding frenzy.

-cc

[Guest]

One idea I toyed with when designing the language was the possibility of designing a terminal shape by vertices. That would be a pretty general solution and allow anything as one shape -- anything from an equilateral triangle to a rhombus to a letter of the alphabet.

For example, you could define something like this:

rule right_triangle {
POLYGON (0,0) (0,1) (1,0) {}
}

"polygon" would be a terminal symbol like square and circle, but it would take a list of points as vertices before the rules that followed it.

Well, from what I can see, the C++ code actually includes calls to Ellipse and Polygon methods of the canvas object (I haven't been able to track them down, but suspect they may be properties of an inherent Windows object). So, being able to pass coordinates might not be out of line.

[chris]

Well, from what I can see, the C++ code actually includes calls to Ellipse and Polygon methods of the canvas object (I haven't been able to track them down, but suspect they may be properties of an inherent Windows object). So, being able to pass coordinates might not be out of line.

Yeah, I think this would be a very easy thing to implement. It's more a question of whether it's the best solution for CFDG. It would be pretty cool to be able to simply draw a really long rectangle or triangle if you wanted, without wasting render time on piecing it together out of squares. But every little thing added to CFDG makes it less pure and appealing in an academic sense.

cc

[MtnViewJohn]

One implementation problem with generic polygon primitives is that it makes the amount of data in a finished shape variable. This would require some trickiness to implement, such as stuffing all unique polygons in all rules into a table on the side and then only keeping a table index in the finished shape data structure.

But I like the idea of having PATH and FILL primitives instead. PATH would simply draw a line from the end-point of the last line, like a line-to operation. The first PATH in a rule would act like move-to.

Code: Select all

rule LineTri {
  PATH { y 10 }
  PATH { y 10 r -60 s 0.5 }
  PATH { y 10 r 60 s 0.5 }
  PATH { y 10 s 0.5 }
}

The next PATH after a FILL would be a move-to, like the first PATH in a rule. Note that I show the rotate inside the LINE primitive affects the x and y parameters. Currently, rotates happen after translates, so I'm not sure this is the way to go. But until we have a way to specify translation in polar coordinates I see no reason to let the rotate parameter go to waste. What else could it possibly mean inside a PATH primitive? Specifying a size of zero is equivalent to a move-to.

FILL draws a line just like PATH. Then it draws a closing line back to the first point in the PATH and fills the closed path.

Code: Select all

rule FillTri {
  PATH { y 1 s 0 }
  PATH { y 1 r -60 s 0 }
  FILL { y 1 r 60 s 0 }
}

You should be able to control whether the line segment joints are round, mitered, or beveled and whether the line endcaps are round or square. You should be able to control whether the fill rule is even-odd or non-zero winding (or no fill).

[chris]

I like the PATH/FILL idea a lot.

[headhammer]

why not introduce x-scale and y-scale attributes?
it's the logical next step from the size attribute, and would very easily allow for ellipses and faux 3d stuff.

[buckyboy314]

See my post about translation for a useful extension to x and y scaling.