Context Free Art

Version 3 Ideas

From Context Free Art

Jump to: navigation, search

Contents

Feature Ideas

The two main features that are driving version 3 are parameters or arguments for rules and having a random number function that is different each time a rule is executed.

Some other feature ideas are: 

rule sinewave {
    360* {x 1} 
        CIRCLE { y (90 * sin($0)) }
}
But Mark thinks that this is ugly and obscure and that it would be better to have an alternate loop syntax with a named loop index variable: 
rule sinewave {
    for (angle = 0; angle < 360; ++angle; {x 1}) {
        CIRCLE { y (90 * sin(angle)) }
    }
}
or maybe 
rule sinewave {
    for angle => 0 .. 360 {x 1} 
        CIRCLE { y (90 * sin(angle)) }
}
if we want to keep loop indices in the integer domain.

kipling's wish list

These are ideas of varying quality, based on what I feel like suggesting just now, as well as some of the forum discussions.

Opinions on MtnViewJohn's list

I am pretty sure it is the case that the ability to add parameters to the rules actually moves the grammar to a different class, in that the language L = {abc,aabbcc,aaabbbccc,....} can be generated by a "parameterised CFG", but not a "CFG" - I suspect this makes it an indexed grammar but you would have to ask an expert on formal languages. This is certainly true if you allow parameters to be integers and are allowed to do arithmetic with them, and I suspect it is also true if the parameters are strings of non-terminal symbols on which you are only allowed to do CF expansion. I think the latter is possible via in your "closure parameters" as described below - admittedly I am not sure that I have grasped closure params completely.
Of course, this may be a bit too esoteric to matter - I mean we already have a seed of non-CF behaviour via the size-threshold bail-out rule. I understood the existing bail-out as a means to an end - the images CF creates are only approximations to the "true" images that are produced where we are visualising a non-terminating expansion process via a CF grammar. The bail-outs allow this approximation by saying "this shape is too small to matter". Given this, an ideal bail-out rule should have the property that as the threshold converges to 0, the image should converge to a "final" image.
I think my next .cfdg will be an infinite number of angels dancing on the heads of an infinite number of pins, skewering infinitely many angels, ...


Language enhancement ideas

CF program ideas

Transform and Closure Parameters

The basic idea of transform parameters (both global and local) is that you could take some list of shape adjustments like s 0.5 y 0.25 b 0.25 h 2 z 1 and pass it to a shape rule, like so: 

rule foo {
    bar ({s 0.5 y 0.25 b 0.25 h 2 z 1}) {x 4}
}
 
rule bar (transform baz) {
    SQUARE {exec $baz}
}
Where rule foo takes the list of shape adjustments s 0.5 y 0.25 b 0.25 h 2 z 1 and passes them to rule bar, which has a parameter of type transform named baz. Within rule bar the baz parameter can be applied anywhere that a shape adjustment can go.

The basic idea of closure parameters is that you take a list of shapes like 

bam1 {s 4 h 160 sat 0.9 b 1 z -1}
bam2 {s 4 h 160 sat 0.9 b 1 z -2}
5 * {r 72} {
    trunkr {y 0.2}
    trunkr {r 180 y -1.6 s 0.4}
}
and pass it to a rule. The rule can then execute the closure, which causes all of the shapes in the closure to get inserted into the rule. Why are we calling this a closure and not an anonymous rule? Because if the closure contains references to rule parameters or loop index variables from the surrounding rule then these values are bound to the closure. When the rule the receives the closure parameter executes the closure the closure will still be able to access these bound values, even though the shape that they came from has already completed its execution and gone away.

What is and is not enclosed in the closure?

The parameters and loop variables in the source shape are bound to the closure. But the world state (affine transform, color, z, random number seed) is not. When a rule executes a closure it provides a world state for the closure.

Isn't a transform parameter also a closure?

I think it is. There is nothing stopping the shape adjustments in a transform parameter from referencing rule parameters or loop variables, unless we explicitly forbid it (which would be bogus). So transform parameters will also have parameters and loop variables from the source rule bound to them. So really there are two kinds of closure parameters: transform and shape. The only difference is the context of where the closure is executed.

TorfusPolymorphus' wish list

Guigui's wish list

(The MtnViewJohn's sentence "Adding a concept of shape time so that the designer has explicit control over what animation frames a given shape is visible." is not so clear to me and maybe it tells something equivalent.) 

startshape EG
rule EG {
    DECREASE_ALPHA{x -2}
    INCREASE_ALPHA{x 2}
    DECREASE_SATURATION{x -2 y -3}
    INCREASE_SATURATION{x 2 y -3}
    DECREASE_BRIGHTNESS{x -2 y -6}
    INCREASE_BRIGHTNESS{x 2 y -6}
}
rule DECREASE_ALPHA {
   DECREASE_ALPHA{s .9 x .95 r 40 alpha -.1}
		// IT'S WORKING
   EG_SHAPE{}
}
rule INCREASE_ALPHA {
   INCREASE_ALPHA{s .9 x .95 r 40 alpha .1}
		// IT'S NOT WORKING
   EG_SHAPE{}
}
rule DECREASE_SATURATION {
   DECREASE_SATURATION{s .9 x .95 r 40 sat -.1}
		// IT'S NOT WORKING
   EG_SHAPE{}
}
rule INCREASE_SATURATION {
   INCREASE_SATURATION{s .9 x .95 r 40 sat .1}
		// IT'S WORKING
   EG_SHAPE{}
}
rule DECREASE_BRIGHTNESS {
   DECREASE_BRIGHTNESS{s .9 x .95 r 40 b -.1}
		// IT'S NOT WORKING
   EG_SHAPE{}
}
rule INCREASE_BRIGHTNESS {
   INCREASE_BRIGHTNESS{s .9 x .95 r 40 b .1}
		// IT'S WORKING
   EG_SHAPE{}
}
rule EG_SHAPE {CIRCLE{alpha -.5 sat .5 b .5}}

FireLizzard's Wish List

SHiNKiROU's Wish List 

rule main {
  SQUARE { }
  main { x 1 }
}

However, it will be awesome of we can interpolate the transformations with experssion functions, so we can make sine wave or these complex curves. 

interpolation SINE(aa) sin(aa / 10)
 
rule main {
  SQUARE { }
  main { x 1 * SINE(depth) }
}
The 
depth
will increase by the recursion depth, and it can be pushed popped or resetted. 
rule main(depth) {
  SQUARE { }
  main (depth + 0.1) { x sin(depth) y 1 }
}

phonx's wish list

Implementation

We are thinking that the best way to implement expressions with random numbers and rules with parameters is to compile the cfdg file to a virtual machine. Otherwise we would have to compile the cfdg file to a syntax tree and re-interpret the tree each time a rule is executed. Compiling to a VM just seems easier. If we use a JITting VM then we probably even get a speed boost. VM candidates are:

Retrieved from "http://www.contextfreeart.org/mediawiki/index.php/Version_3_Ideas"
Views
Personal tools
Navigation
Toolbox
Powered by MediaWiki
Attribution-Share Alike 2.5
book coverSee our book:
Community of Variation