A suggestion for an additional way to describe a cfdg grammar

rubyFeedback commented

2021-03-06 17:18:49 +01:00

(Migrated from github.com)

Before I explain my suggestion, allow me to copy/paste the current .cfdg I am working on; it was
written by someone else for a grass-pattern.

startshape field

tile {s 150 }
background { hue 83.1 sat 0.4664 b -0.1255}

rule field
{
  grass{hue 97.6 sat 0.7282 b 0.7647}
}

# Add a chance to add a seedling. 
rule grass 5
{
  seedling{}
  grass{}
}

rule grass
{
  grass{b 0.2}
}

rule grass
{
  grass{b -0.1}
}

rule grass
{
  grass{hue 0.1}
}

rule grass
{
  grass{hue -.1}
}

rule grass
{
  grass{sat 0.01}
}

rule grass
{
  grass{sat -.01}
}

rule grass 10
{
  grass{r 5}
}

rule grass 10
{
  grass{r -5}
}

rule grass
{
  grass{r 180}
}

rule grass
{
  grass{x 10}
}

rule grass
{
  grass{x -10}
}

rule grass
{
  grass{y 10}
}

rule grass
{
  grass{y -10}
}

rule grass 0.01
{
  // end
}

rule seedling
{
  SQUARE{}
  seedling{y 1 r -2 s 0.991}
}

rule seedling
{
  SQUARE{}
  seedling{y 1 r 2 s 0.991}
}

I have been thinking about that. The rule {} entries actually look like method
calls in a programming language.

We also have things such as:

rule grass 5

which I think is ultimately a probability value, right?

So what if we could actually turn that into a programming-language or programming-like
language?

Say we have a common entry point which we call "main". That way we can remove the
startshape-clause. Each individual rule could be constructed like a method.

For example:

rule grass 5
{
  seedling{}
  grass{}
}

Could perhaps become:

def grass(probability: 5)
  seedling()
  grass()

We could use python-like syntax based on indent, or ruby-like syntax where
each "def" ends with "end". (I don't like the python requirement for a ":" after
the def, though. Indent alone should be enough.)

So why do I make this suggestion at all? Well, I think that the existing way to
build up such a context-free generated image, could also be done in a
programming-centric fashion. Perhaps this may be simpler for some folks.
We could also use aliases so that things such as "b -1.0" could be more
verbose, if the user wants to.

For example:

{y 1 r -2 s 0.991}

I think many new users have no idea what these single letters mean. They
can look at the wiki, yes, but I wonder whether it may not be better to simply
allow for a style such as:

y_axis: 1
radius: -2
scale: 0.991

(I made up the names here, but you get the idea.)

Anyway - not sure how likely it is to add alternative set of rules or grammar
but I wanted to suggest it. Note that I do NOT mean to obsolete the old
rules! These should be kept for many reasons, including compatibility,
but also because many other users will probably prefer the old way. Thus
my suggestion is for an ADDITIONAL way. (And perhaps we can cross-translate
it once it exists, so people can always adjust to what they prefer to use.)

Please feel free to close this issue - it is mostly meant as a suggestion for
future changes.

Before I explain my suggestion, allow me to copy/paste the current .cfdg I am working on; it was written by someone else for a grass-pattern. startshape field tile {s 150 } background { hue 83.1 sat 0.4664 b -0.1255} rule field { grass{hue 97.6 sat 0.7282 b 0.7647} } # Add a chance to add a seedling. rule grass 5 { seedling{} grass{} } rule grass { grass{b 0.2} } rule grass { grass{b -0.1} } rule grass { grass{hue 0.1} } rule grass { grass{hue -.1} } rule grass { grass{sat 0.01} } rule grass { grass{sat -.01} } rule grass 10 { grass{r 5} } rule grass 10 { grass{r -5} } rule grass { grass{r 180} } rule grass { grass{x 10} } rule grass { grass{x -10} } rule grass { grass{y 10} } rule grass { grass{y -10} } rule grass 0.01 { // end } rule seedling { SQUARE{} seedling{y 1 r -2 s 0.991} } rule seedling { SQUARE{} seedling{y 1 r 2 s 0.991} } I have been thinking about that. The rule {} entries actually look like method calls in a programming language. We also have things such as: rule grass 5 which I think is ultimately a probability value, right? So what if we could actually turn that into a programming-language or programming-like language? Say we have a common entry point which we call "main". That way we can remove the startshape-clause. Each individual rule could be constructed like a method. For example: rule grass 5 { seedling{} grass{} } Could perhaps become: def grass(probability: 5) seedling() grass() We could use python-like syntax based on indent, or ruby-like syntax where each "def" ends with "end". (I don't like the python requirement for a ":" after the def, though. Indent alone should be enough.) So why do I make this suggestion at all? Well, I think that the existing way to build up such a context-free generated image, could also be done in a programming-centric fashion. Perhaps this may be simpler for some folks. We could also use aliases so that things such as "b -1.0" could be more verbose, if the user wants to. For example: {y 1 r -2 s 0.991} I think many new users have no idea what these single letters mean. They can look at the wiki, yes, but I wonder whether it may not be better to simply allow for a style such as: y_axis: 1 radius: -2 scale: 0.991 (I made up the names here, but you get the idea.) Anyway - not sure how likely it is to add alternative set of rules or grammar but I wanted to suggest it. Note that I do NOT mean to obsolete the old rules! These should be kept for many reasons, including compatibility, but also because many other users will probably prefer the old way. Thus my suggestion is for an ADDITIONAL way. (And perhaps we can cross-translate it once it exists, so people can always adjust to what they prefer to use.) Please feel free to close this issue - it is mostly meant as a suggestion for future changes.

MtnViewJohn commented

2021-03-07 02:44:10 +01:00

(Migrated from github.com)

The single letter abbreviations already have long variants, except for x, y, and z. r and rotate are interchangeable, same for s and size, f and flip, trans and transform, h and hue, sat and saturation, b and brightness, a and alpha. skew has always just been skew, same with time and timescale.

We have already done a compatibility-breaking syntax change going from cfdg 2.x to cfdg 3.x. The code you are working with is in the old syntax, you can translate it here. I don't want to do another major syntax change unless it brings compelling new features.

On a side note, your code does randomness in the cfdg 2 manner, where random rule selection is the only way to make a shape do different things. With cfdg 3 you can have random actions inside a rule. Your grass code can be reduced to 5 rules:

startshape field

tile {s 150 }
background { hue 83.1 sat 0.4664 b -0.1255}

rule field
{
  grass{hue 97.6 sat 0.7282 b 0.7647}
}

# Add a chance to add a seedling. 
rule grass 5
{
  seedling{}
  grass{b -0.1…0.2 hue -0.1…0.1 sat -0.01…0.01
        r -5…5 x -10…10 y -10…10}
}

rule grass 0.1
{
  grass{r 0…360}
}

rule grass 0.01
{
  // end
}

rule seedling
{
  SQUARE{}
  seedling{y 1 r -2…2 s 0.991}
}

The single letter abbreviations already have long variants, except for x, y, and z. **r** and **rotate** are interchangeable, same for **s** and **size**, **f** and **flip**, **trans** and **transform**, **h** and **hue**, **sat** and **saturation**, **b** and **brightness**, **a** and **alpha**. **skew** has always just been **skew**, same with **time** and **timescale**. We have already done a compatibility-breaking syntax change going from cfdg 2.x to cfdg 3.x. The code you are working with is in the old syntax, you can translate it [here](https://www.contextfreeart.org/gallery/translate.php). I don't want to do another major syntax change unless it brings compelling new features. On a side note, your code does randomness in the cfdg 2 manner, where random rule selection is the only way to make a shape do different things. With cfdg 3 you can have random actions inside a rule. Your grass code can be reduced to 5 rules: ```cfdg startshape field tile {s 150 } background { hue 83.1 sat 0.4664 b -0.1255} rule field { grass{hue 97.6 sat 0.7282 b 0.7647} } # Add a chance to add a seedling. rule grass 5 { seedling{} grass{b -0.1…0.2 hue -0.1…0.1 sat -0.01…0.01 r -5…5 x -10…10 y -10…10} } rule grass 0.1 { grass{r 0…360} } rule grass 0.01 { // end } rule seedling { SQUARE{} seedling{y 1 r -2…2 s 0.991} } ```

synxroform commented

2021-08-13 16:41:44 +02:00

(Migrated from github.com)

It is undesirable to elliminate startshape keyword, because it's a good way to switch between different branches during debugging. In the node based systems like Fusion, Nuke or Touchdesigner you can change the current node you want to output to the screen, just think of it in similar way.

MtnViewJohn commented

2021-08-15 21:50:29 +02:00

(Migrated from github.com)

I would never get rid of startshape. But I should make it optional. If there is no startshape then the first shape in the file is the startshape. I would rather do this than pick a default startshape name like main or scene because many non-english speakers use Context Free.

I think that adding a Pythonic syntax is a non-starter. But I would be interested in a ContextFree module for Python. I only know a little about Python. But it seems to me that function decorators could be used to allow shape rules to be expressed as Python code. The AGG rendering engine could be bound to Python as a C++ library. It would be a fun project for someone who knows a lot of Python. I would be glad to help if someone wanted to do this.

I would never get rid of startshape. But I should make it optional. If there is no startshape then the first shape in the file is the startshape. I would rather do this than pick a default startshape name like **main** or **scene** because many non-english speakers use Context Free. I think that adding a Pythonic syntax is a non-starter. But I would be interested in a ContextFree module for Python. I only know a little about Python. But it seems to me that function decorators could be used to allow shape rules to be expressed as Python code. The AGG rendering engine could be bound to Python as a C++ library. It would be a fun project for someone who knows a lot of Python. I would be glad to help if someone wanted to do this.

Rows
Columns

A suggestion for an additional way to describe a cfdg grammar #38