Some ideas for Context Free 3.0

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
MtnViewJohn
Site Admin
Posts: 837
Joined: Fri May 06, 2005 2:26 pm
Location: Mountain View, California
Contact:

Some ideas for Context Free 3.0

Post by MtnViewJohn » Fri May 04, 2007 9:23 am

What should be the next round of feature additions to Context Free? What do you find hard that you wish was easier? Here are some of the things I am thinking about:

Stronger loop syntax: Instead of just having a single shape in a loop you could have a whole list of shapes, including other loops:

Code: Select all

rule grid5 {
    5* {y 1} {
        5* {x 1} CIRCLE {}
    }
} 
Continuations: Currently you can only pass color and shape transform from one shape to another, but with continuations you could wrap up a bunch of shape replacements and pass them to a shape. The receiving shape can execute them, pass them on to another shape, or wrap the continuation and some additional shapes up and pass them to another shape:

Code: Select all

rule grid5 {
    5* {y 1} {
        5* {x 1} CONTINUATION {}
    }
} 

rule foo {
    grid5{ {CIRCLE {} SQUARE {s SQRT(2)/2 b 1}}
} 
Continuations could also be used to implement proportional spaced fonts:

Code: Select all

rule Hello {
    H{{e{{l{{l{{o{}}}}}}}}}
}

rule H {
    H_glyph{}
    CONTINUATION {x 0.95}
} 
Expressions: Anywhere you can have a number you can have an expression. Expressions can include various trig and math functions.

Parameterized rules: Rules can take numeric parameters that are like function parameters:

Code: Select all

rule grid<n> {
    $n* {y 1} {
        $n* {x 1} CONTINUATION {}
    }
} 

rule ring<n, r> {
    $n* {r 360/$n} CONTINUATION{x $r}
}

rule foo {
    grid<5>{ {CIRCLE {} SQUARE {s SQRT(2)/2 b 1}}
    ring<20, 2.5> {x 2.5 y 2.5 z 1 {CIRCLE {b 1 s 0.2}}}
} 
The startshape line can have parameters that can be overridden by the user. You could create a movie based on parameterized frames instead of dividing shapes into frames.

Continuations would get there parameters resolved before they get wrapped up. Maybe it would be nice to support color changes and affine transforms as parameters in addition to numbers.

Maybe continuations are in the parameter list instead of the shape adjustment list. Then you could pass multiple continuations into a shape.

Polygons: Arbitrary polygons can be specified by having a list of VERTEX primitive shapes followed by one or more FILL and STROKE primitive shapes. The vertex list can be one or more distinct sets of vertices that can each be open or closed. You would be able to punch a hole in a polygon using either even-odd rules or nonzero rules.

Arcs: You could insert circles or arc segments into polygon vertex lists using a new ARC primitive shape, that takes start and end angles as parameters:

Code: Select all

 rule heart {
    ARC<0, 180> {x 1}
    ARC<0, 180> {x -1}
    VERTEX {y -2}
    CLOSE{}
    FILL {b 1 sat 1}
} 
More than one color: Allow a shape to support more than one color. In addition to the current hue, sat, b adjustments there would be hue1, sat1, b1, hue2, sat2, b2, etc. You would be able to control which color is used to paint a given shape.

Virtual machine: Not really a feature, but an implementation change. The cfdg files would compile to byte-codes instead of raw shape lists. A virtual machine would then execute the startshape directive to produce a list of primitive shapes that are then rendered.

User avatar
pakin
Posts: 40
Joined: Sat Apr 21, 2007 8:59 pm
Location: United States
Contact:

Post by pakin » Sat May 05, 2007 11:48 am

Those ideas all sound good. The following are some additional thoughts I have.
Expressions: Anywhere you can have a number you can have an expression. Expressions can include various trig and math functions.
Currently, some attributes are multiplicative (e.g., size); some are additive (e.g., hue); some are thresholded (e.g., brightness); some wrap around (e.g., hue). I'd like to see a more consistent way of performing shape adjustments, in which any attribute can be modified in any way. As you mentioned expressions, perhaps it would be a good idea for shape adjustments to be statements. For example,

Code: Select all

SQUARE { size 0.5 hue 30 }
would instead be expressed as

Code: Select all

SQUARE { size*=0.5  hue=(hue+30)%360 }
What's exciting about this approach is that it can be used for attributes whose values are relative to the original transformation matrix, not just to the previous transformation matrix. For example, a shadow could be implemented by drawing an object shifted to the right and downwards by a fixed amount, regardless of which direction "right" and "down" refer to in the current transformation matrix.
Parameterized rules: Rules can take numeric parameters that are like function parameters:
Why limit parameters to numbers? How about also supporting first-class transformation matrices that can be passed from rule to rule? Consider, for example, trying to produce a red-blue anaglyphic stereogram. By being able to pass transformation matrices and adjust each a shape's attributes relative to a different matrix one could scale an object relative to, say, the parent object but then draw a duplicate of the object shifted based on the current 3-D depth.

Speaking of duplicates, another potentially useful parameter to be able to pass would be the current random-number seed. With that, it would be possible to draw exact duplicates of a randomly generated shape -- useful for shadows, anaglyphs, and probably some other nifty designs that someone more clever than I will think of.

Finally, how about implementing bounded recursion? The current assumption in Context Free is that a drawing will terminate when the leaf objects are too small to be seen or when a nonrecursive rule is selected on each branch of the recursion. Consider, however, a figure in which each subfigure stays the same size but spreads out over the plane. The only way to implement that in the current version of Context Free is to probabilistically terminate the recursion. It may come in handy for the next version to enable a rule to recurse to a given depth -- parameterized rules can help make this possible -- then stop.

Looking forward to the next major version of Context Free,
-- Scott

User avatar
markie
Posts: 12
Joined: Wed Dec 27, 2006 7:20 pm
Location: Rotterdam; The Netherlands
Contact:

Post by markie » Sat May 05, 2007 2:13 pm

Wow! good ideas;
On one hand, the power of cf lies in its simplicity; creative challenge (for me at least) is in the limitations, and finding ways to work around them.
On the other hand, new features make more possible...
I hope CF will keep it's clarity in some way.

If I were to choose, i'd go for parametrization & the posibility to create frames for movies.

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

Post by MtnViewJohn » Sat May 05, 2007 4:07 pm

pakin wrote:Those ideas all sound good. The following are some additional thoughts I have.
Expressions: Anywhere you can have a number you can have an expression. Expressions can include various trig and math functions.
Currently, some attributes are multiplicative (e.g., size); some are additive (e.g., hue); some are thresholded (e.g., brightness); some wrap around (e.g., hue). I'd like to see a more consistent way of performing shape adjustments, in which any attribute can be modified in any way. As you mentioned expressions, perhaps it would be a good idea for shape adjustments to be statements. For example,

Code: Select all

SQUARE { size 0.5 hue 30 }
would instead be expressed as

Code: Select all

SQUARE { size*=0.5  hue=(hue+30)%360 }
What's exciting about this approach is that it can be used for attributes whose values are relative to the original transformation matrix, not just to the previous transformation matrix. For example, a shadow could be implemented by drawing an object shifted to the right and downwards by a fixed amount, regardless of which direction "right" and "down" refer to in the current transformation matrix.
But what would it mean to say size+=5? We are kind of committed to using affine transform matrices as the underlying representation of shape state and addition of affine transform matrices is not really a meaningful operation. At least as far as I know.

Hues are additive and sat/bright/alpha are thresholded because that is what is most useful for the HSV color space, in which hue wraps around and sat/value/alpha do not. You can get threshold behavior for hue by using hue targets. Maybe we could have the ability to control whether hue/sat/bright/alpha wrap or peg at 0/1 (or 0/360 for hue). Color dimension changes would then be additive for wrapping color space dimensions and thresholded for pegged color space dimensions.

Implementing things like drop shadows could be done using affine transforms as parameters, which I did mention farther down in my post. You would generate the affine transform for the drop shadow before doing any rotates or scales and then pass it down unchanged as a parameter.
Parameterized rules: Rules can take numeric parameters that are like function parameters:
Why limit parameters to numbers? How about also supporting first-class transformation matrices that can be passed from rule to rule? Consider, for example, trying to produce a red-blue anaglyphic stereogram. By being able to pass transformation matrices and adjust each a shape's attributes relative to a different matrix one could scale an object relative to, say, the parent object but then draw a duplicate of the object shifted based on the current 3-D depth.
I agree that parameters should be more than just numbers. They should include affine transforms, color changes and possibly continuations.

Speaking of duplicates, another potentially useful parameter to be able to pass would be the current random-number seed. With that, it would be possible to draw exact duplicates of a randomly generated shape -- useful for shadows, anaglyphs, and probably some other nifty designs that someone more clever than I will think of.
Allowing manipulation of the random number seed would violate the context free grammar paradigm. The only context free way around this is to define special drawing canvases. Tiling is done using a tiling canvas that applies a translation symmetry operation to the output of the context free grammar. You could define rotation symmetry canvases, mirror symmetry canvases, shadow generating canvases, etc.

Finally, how about implementing bounded recursion? The current assumption in Context Free is that a drawing will terminate when the leaf objects are too small to be seen or when a nonrecursive rule is selected on each branch of the recursion. Consider, however, a figure in which each subfigure stays the same size but spreads out over the plane. The only way to implement that in the current version of Context Free is to probabilistically terminate the recursion. It may come in handy for the next version to enable a rule to recurse to a given depth -- parameterized rules can help make this possible -- then stop.
I did implement this but got spanked by Mark and Chris for violating the context free paradigm, so out it went. The strong loop syntax should give you what you need.

Looking forward to the next major version of Context Free,
-- Scott

User avatar
Guigui
Posts: 50
Joined: Sat Aug 05, 2006 5:28 pm
Location: Annecy, France

Post by Guigui » Fri Jun 08, 2007 2:37 pm

I agree with Markie about this great announcement:
1st -> WOW
2nd -> I do like the sobriety of CF but it will be thrilling to discover new possibilities.
3rd -> I also hope CF will keep its clarity
4th -> Some abilities for animation would be great

BTW, I'm not sure of what you mean here:
The startshape line can have parameters that can be overridden by the user. You could create a movie based on parameterized frames instead of dividing shapes into frames.
especially "parameters that can be overridden by the user".

Also,
I don't understand the purpose of More than one color.

But, even if I'm not a computer specialist, I think I've understood your explanations about Polygons, Parameterized rules & Continuations.

For animation, what about a TimeValue that can be use as a value. With TimeValue=1 for the first frame, TimeValue=2 for the second frame, etc…

Last thing, for mac users (like me 8^D), would it be hard to make CF scriptable with AppleScript? For instance, it would make possible serial rendering.

Have a good day MtnViewJohn (& Mark and Chris)
8^)

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

Post by MtnViewJohn » Fri Jun 08, 2007 6:30 pm

Guigui wrote:I agree with Markie about this great announcement:
1st -> WOW
2nd -> I do like the sobriety of CF but it will be thrilling to discover new possibilities.
3rd -> I also hope CF will keep its clarity
4th -> Some abilities for animation would be great

Yes, we don't want CF to become an enormous mess like Perl.
Guigui wrote:BTW, I'm not sure of what you mean here:
The startshape line can have parameters that can be overridden by the user. You could create a movie based on parameterized frames instead of dividing shapes into frames.
especially "parameters that can be overridden by the user".
If the rule specified in the startshape line is a rule that takes parameters then the startshape line needs to supply parameters. But you should be able to type different parameters into an edit window, click 'Render' and expect CF to use your parameters instead of the ones in the startshape line.
Guigui wrote: Also,
I don't understand the purpose of More than one color.
Haven't you ever though it limiting to only have one color? Right now a shape can only pass one color to its children and all child shape colors are derived from that one color. I want to add more colors.
Guigui wrote:But, even if I'm not a computer specialist, I think I've understood your explanations about Polygons, Parameterized rules & Continuations.

For animation, what about a TimeValue that can be use as a value. With TimeValue=1 for the first frame, TimeValue=2 for the second frame, etc…
That's a great idea. We were never certain that the area=time paradigm was right. It would be nice to leave it completely to the user.
Guigui wrote:
Last thing, for mac users (like me 8^D), would it be hard to make CF scriptable with AppleScript? For instance, it would make possible serial rendering.
Probably, I'll look into it. cfdg, the command-line version, compiles fine in XCode. It just doesn't do QuickTime movies or create rectangular tiled images.
Guigui wrote:
Have a good day MtnViewJohn (& Mark and Chris)

shevegen
Posts: 57
Joined: Wed Jul 06, 2005 5:38 am

Post by shevegen » Thu Jul 05, 2007 10:20 am

By the way, please also make a small/short tutorial, i.e. an example, on how to use such new features. People like me tend to learn a bit slower :-)

alpt
Posts: 5
Joined: Thu Nov 01, 2007 2:04 pm
Contact:

Shell expansion

Post by alpt » Fri Nov 02, 2007 5:47 am

It would be nice to have something like:

Code: Select all

rule sin {
  $(#!/usr/bin/python
     import math
     for i in range(-500,500):
        print "CIRCLE { x", i, "y %0.9f"%(math.sin(i/100.)*100), "}"
    )
}
The same can be applied to parameters too:

Code: Select all

$n * { r 10 } CIRCLE{}
Where $n is a SHELL variable, i.e. a variable of ENV.
In this way, it will possible to pass options before the rendering:

Code: Select all

     n=36 ./cfdg test.cfdg out.png
[/code]

User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Remaining context free

Post by zol » Fri Mar 28, 2008 12:54 am

(Re: Parameterisation and context-freeness.)

Well, I instinctively hoped for something a bit more intriguing, but after sorting out the angles all I was left with this.

CF criterion: Outcomes are independent of branch traversal order.

That's it.
Or, less abstractly: Siblings cannot share information.
Or, in programming terms: No return values.


It also keeps things conceptually tidier to insist that any variables have strictly local scope and any parameters are passed by value only.

So, it turns out to be pretty easy to parameterise without risking context-awareness.

What's really at stake here is new information not implicit in the code structure: non-deterministic branching, random values, other external sources.
Those are the events that really test context awareness.

Context free recursion bounds
What's the problem? We already have them.
Unfortunately, they are currently assigned to brightness instead of vitality. :P
You know... When vitality drops below a certain threshhold, the rule blacks-out :wink:

Oh yeah, and I'll just take this opportunity to raise my hand for script-defined, compile-time evaluated constants.
Surprised no-one else mentioned it.
Well, I saw one topic about it, under the rubric "immutable variables"

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

Re: Remaining context free

Post by MtnViewJohn » Fri Mar 28, 2008 8:12 am

zol wrote:Context free recursion bounds
What's the problem? We already have them.
Unfortunately, they are currently assigned to brightness instead of vitality. :P
You know... When vitality drops below a certain threshhold, the rule blacks-out :wink:
There is nothing wrong with them in general. It's just that the cheap, easy implementation that I had in mind was not context-free. Once we have parameters then all it takes is to have some sort of if statement to have recursion limits.
zol wrote:Oh yeah, and I'll just take this opportunity to raise my hand for script-defined, compile-time evaluated constants.
Surprised no-one else mentioned it.
Well, I saw one topic about it, under the rubric "immutable variables"
Yes, once rules have parameters then the whole cfdg file should have global parameters too. And there should also be a way to provide global parameters from the command line or some sort of render parameters dialog window.

User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Post by zol » Tue Apr 08, 2008 7:06 am

(I assume it's okay to use this thread for additional suggestions)
Just a small one -
Option to have the variation code incorporated into the output filename.

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

Post by MtnViewJohn » Tue Apr 08, 2008 8:35 am

zol wrote:(I assume it's okay to use this thread for additional suggestions)
Just a small one -
Option to have the variation code incorporated into the output filename.
That option already exists. Look in the preferences dialog for 'Include the variation code in the file name'.

User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Post by zol » Tue Apr 08, 2008 1:07 pm

I meant the commandline version, sorry.

I can of course use a script to to extract the code from standard output and rename the file when DONE!, but it's a bit of a kludge.

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

Post by MtnViewJohn » Tue Apr 08, 2008 8:26 pm

zol wrote:I meant the commandline version, sorry.

I can of course use a script to to extract the code from standard output and rename the file when DONE!, but it's a bit of a kludge.
OK. That looks pretty easy.

User avatar
zol
Posts: 40
Joined: Sun Mar 23, 2008 4:14 pm

Post by zol » Thu Apr 17, 2008 12:43 am

I don't know what the timescale or limitations are on 3.0, so I'll just carry on here.

Invertible colour dimensions

The implementation I have in mind does not change the absolute value, just as flipping does not move the origin is absolute space.
It only changes the relationship between relative and absolute axes.
Internally, each dimension has a flag for which mode it is in, but is otherwise unchanged.
Adjustments are calculated in exactly the same way.
The only difference is that rules no longer know which way is 'up' in absolute terms.

Hue inversion just changes which direction is positive without changing the relative value.

For the others: v' = 1-v
The relative value is changed when the axis is inverted so that the absolute value is retained.
At rendering time, any inverted values are just inverted again to yeild absolute values.

This applies to both Target and Expressed colour components.

This detachment of relative from absolute values simplifies at least one pretty basic idiom.

Code: Select all

rule concentric{ CIRCLE{} concentric[s .9 b 1 bi] }
The ability to cheaply alternate black and white can yeild interesting and rewarding effects from the simplest experiments which might otherwise be missed inside a black blob.
(I suspect that people are more inclined to experiment in black and white than {b 1 sat 1 h 180}.)

This construction is actually an attractor, so any adjustment will lead to alternation between the appropriate complementary pair - no math required.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest