Preemptive - what not to suggest for expanding CFDG!

Let the developers know what you think of the software and what can be done to either improve the CFDG language or the Context Free program.

Moderators: chris, MtnViewMark, MtnViewJohn

User avatar
chris
Site Admin
Posts: 72
Joined: Wed May 04, 2005 10:57 am
Location: New York, NY
Contact:

Preemptive - what not to suggest for expanding CFDG!

Post by chris » Fri May 06, 2005 9:16 am

In an abstract sense, the CFDG language is interesting -- and appropriately named -- for the reason that all design rules are context-free. (Search google for "context free grammar" if you want to learn more about that). With that in mind, we'd rather not add anything to the language that violates this principal.

For examples: passing variables to child shapes, limiting the number of times a certain rule can be used, positioning things absolutely, and declaring a specific color -- these are all context "sensitive" rules. By including those things CFDG isn't CF anymore.

One logical expansion of CFDG is to move to 3D (or even 4D/animations). I don't personally have an interest in it, but maybe someone will volunteer in the development forum. It shouldn't be particularly hard -- the big question will be how to output the files. Povray? Some other rendering software? I'm curious where this could go, but personally I don't wish to add it right now...and I suspect Mark and John don't wish to add it to the Context Free program.

That said, add your suggestions here!

-Chris
Current Project: I'm creative director of OKCUPID at http://www.okcupid.com

David Spitzley
Posts: 21
Joined: Fri May 06, 2005 10:01 am

Post by David Spitzley » Fri May 06, 2005 1:47 pm

Ok, here's what I've come up with so far:

1) red, green, and blue attributes which can be used akin to brightness. The colors would compound as per brightness(i.e. a call to BLOB{b .5}, where BLOB contains CIRCLE{b .75} results in a CIRCLE plotted with brightness .375). Either color will need to trump brightness, vice versa, or brightness could simply be applied uniformly to the three color values (so b .5 applied to a shape which includes red .8 and no mention of blue or green would have red .4, blue .5, green .5

2) An Equilateral triangle object

3) A Right triangle object

4) Ability to set size separately for x and y; this would allow a square to be squashed into a rectangle, or a circle into an ellipse.

User avatar
MtnViewJohn
Site Admin
Posts: 844
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by MtnViewJohn » Fri May 06, 2005 2:35 pm

If we add color I think the best way is to add hue and saturation to the existing brightness. I have a screen saver (http://www.ozonehouse.com/Spirex/index.html) that does random colors and when I worked in RBG space they were often muddy and ugly. Things looked much better when I switched to HSB space.

bigelectricat
Posts: 19
Joined: Fri May 06, 2005 8:43 am

anti-aliased rendering

Post by bigelectricat » Sun May 08, 2005 10:54 pm

how about providing the option to do anti-aliased rendering? it would smooth out the edges especially of rotated objects.

bigelectricat
Posts: 19
Joined: Fri May 06, 2005 8:43 am

specify font style and font family

Post by bigelectricat » Sun May 08, 2005 10:58 pm

another suggestion: being able to assign different fonts (helvetica, times, etc.) and font style (italic, bold, etc.)

User avatar
MtnViewMark
Site Admin
Posts: 81
Joined: Wed May 04, 2005 12:46 pm
Location: Mountain View, CA
Contact:

Re: anti-aliased rendering

Post by MtnViewMark » Mon May 09, 2005 7:39 am

bigelectricat wrote:how about providing the option to do anti-aliased rendering? it would smooth out the edges especially of rotated objects.
See the new F.A.Q. entry: Does it anti-alias?.
I'm the "m" in "mtree.cfdg"

yevgen
Posts: 2
Joined: Mon May 09, 2005 2:00 pm
Location: Montreal, Canada
Contact:

Post by yevgen » Mon May 09, 2005 2:26 pm

Well, I can explain why I made my version of CFDG 'not-absolutely-CF'. Imagine you write a program to draw Xmas-tree with candles. No matter how the branches are located, the candles have to stick in upright position. That's why I extended the syntax a bit to allow absolute values for parameters, e.g. SQUARE {r =0}. Also I've added built-in RECT (empty square) and LINE rules. Anyway, I try to keep backward compatibility with CFDG (I appreciate bug reports on this, as well as any feedback!). My version now supports [kind of] scaling, as well as some other new features. Had not time to thorously test it yet. It's still at korsh.com/cfdg .

bigdrip681

This is a neat program...

Post by bigdrip681 » Wed Jun 08, 2005 5:41 pm

it would be cool to have the program export as a PNG without the white background I.E. Transparent. Other than that this is an awesome program! And deceptively addictive once you get the hang of it :)

Robert

Post Script

Post by Robert » Thu Nov 17, 2005 10:03 am

What about having the ability to export the files to post script? THis way we could open them in a program like Adobe Illustrator.

User avatar
MtnViewJohn
Site Admin
Posts: 844
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by MtnViewJohn » Fri Nov 18, 2005 12:27 am

The output of Context Free often has over a million shapes. Your hard disk would quickly fill up and Illustrator would choke. Even simple images have tens of thousands of shapes.

User avatar
logic
Posts: 8
Joined: Thu Apr 13, 2006 11:16 am

Re: Preemptive - what not to suggest for expanding CFDG!

Post by logic » Thu Apr 13, 2006 11:36 am

chris wrote:In an abstract sense, the CFDG language is interesting -- and appropriately named -- for the reason that all design rules are context-free. (Search google for "context free grammar" if you want to learn more about that). With that in mind, we'd rather not add anything to the language that violates this principal.

For examples: passing variables to child shapes,
[snipped]
If you call them "parameters", only use them for predication and consider the resulting rules to be separate rules, then I don't see how this violates the principle. The basic idea is that no matter what the circumstances are, a rule always does the same thing, right?

Consider:

Code: Select all

rule CURVE(@segments, @anglepersegment)
{
  SQUARE { y 5 s 1 10 }
  (@segments > 0) CURVE(@segments - 1, anglepersegment) { y 10 r (@anglepersegment) }
}
If you think of CURVE(@segments, @anglepersegment) as being not a single rule that takes parameters but rather a class of rules that are generated based on two parameters, then clearly any one of those rules always does the same thing. For instance, the rule CURVE(5, 7) would have a body like:

Code: Select all

{
  SQUARE { y 5 s 1 7 }
  CURVE(4, 7) { y 10 r 7 }
}
..while the (final) rule CURVE(0, 7) would have a simpler body:

Code: Select all

{
  SQUARE { y 5 s 1 7 }
}
Both of these rules always do the same thing, right? In what way is the principle violated? These rules do not have side-effects.

The syntax I have in mind is:
  • All parameter names shall be prefixed by '@' (or some other character, or suffixed, or what have you) to disambiguate them from any parameters (some of which might not have been added yet at the time the rule was created).
  • A "rule class" has a list of parameter names enclosed in parentheses directly following its name.
  • Parameters have only numeric values.
  • An infix expression may be specified at any place a number is expected, provided it is surrounded by parentheses.

    Example:

    Code: Select all

        rule RECTANGLE(@width, @height)
        {
          SQUARE { s (@width) (@height) }
        }
  • If such an expression precedes a rule's name, then it is treated as a boolean which, if false, excludes that statement entirely from the generated rule. As in C, relational operators shall return 0 for false and 1 for true, and any non-zero value shall be considered true for the purposes of predication.
  • When invoking another rule, if the name supplied is that of a rule class and not a single rule, then the designated number of parameters shall follow as a list, enclosed in parentheses, of expressions. These expressions need not themselves be enclosed in parentheses.

    For an example, see the "CURVE" rule class above.
  • This could interact with the looping proposal, such that an expression followed by an asterisk, a transformation expression, and a call to another rule repeats that transformation/rule as many times as the expression denotes.

    Example:

    Code: Select all

        rule CURVE(@segments, @anglepersegment)
        {
          (@segments) * [y 10 r (@anglepersegment)] SQUARE [y 5 s 1 10]
        }
Is this really a violation of the principle of no context?

User avatar
MtnViewJohn
Site Admin
Posts: 844
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by MtnViewJohn » Thu Apr 13, 2006 9:39 pm

No it doesn't violate the context free principle. It is just syntactic sugar for describing a family of rules. You can't do anything with parameterized rules that isn't already possible by writing out lots of similar rules by hand (or by Python script).

But implementing it would be a very large undertaking because it would require huge changes "under-the-hood". Context Free produces an image in 3 stages:
  1. The CFDG file is parsed down to a compact set of data structures.
  2. The rendering algorithm is run on these rules to produce a list of shapes.
  3. And the shapes are then sent to a canvas object to produce an image.
Parsing a CFDG file produces a set of rules, each of which is composed of a list of shape replacements. The shape replacement is simply a number that encodes the shape name, a color delta, and an affine transform matrix that is constructed at parse time from the shape geometry adjustments (r, x, y, skew, etc.).

With parameterized rules the shape replacements would have to be parsed to a much more abstract level and the color change and affine transform would have to be computed at render time instead of parse time. This major change would have to be done before even starting on implementing parameters. So, it's a great idea and might happen sometime, but not within the next 6 months.

User avatar
LazyMoon
Posts: 20
Joined: Sun Aug 13, 2006 2:52 am
Location: Adelaide, Australia
Contact:

Re: This is a neat program...

Post by LazyMoon » Wed Sep 27, 2006 6:08 am

bigdrip681 wrote:it would be cool to have the program export as a PNG without the white background I.E. Transparent.
ContextFree can do that currently, you just have to set your background to be transparent.

background { a -1 }

User avatar
LazyMoon
Posts: 20
Joined: Sun Aug 13, 2006 2:52 am
Location: Adelaide, Australia
Contact:

Post by LazyMoon » Wed Sep 27, 2006 6:10 am

MtnViewJohn wrote:The output of Context Free often has over a million shapes. Your hard disk would quickly fill up and Illustrator would choke. Even simple images have tens of thousands of shapes.
How does this differ from SVG export?

User avatar
MtnViewJohn
Site Admin
Posts: 844
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Post by MtnViewJohn » Fri Nov 10, 2006 4:38 pm

The same problem exists with SVG output. If your design produces too many shapes then your SVG viewer might choke.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests