Shapes too big? But I want them to grow!

If you're having trouble using Context Free or don't understand the language, ask for help here.

Moderators: MtnViewJohn, chris, mtnviewmark

Post Reply
dextroc
Posts: 2
Joined: Tue Feb 27, 2007 4:45 pm

Shapes too big? But I want them to grow!

Post by dextroc »

I was able to let the shapes grow endlessly in version 1.2, but that one didn't have animation rendering. Now that feature has been added, but the shapes won't grow as they used to! Is there some way to turn off the limits, and if so, will the animation rendering stop or just go on endlessly as well? I really want my shapes as animation, they look so cool that way!

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

Post by MtnViewJohn »

If the design grows endlessly then Context Free will never stop. The only way to get it to stop is to hit the Stop button or wait for the 'A shape got too big' error. But once you do this you can save the resulting shapes as an animation. All that saving as an animation does is take all the shapes in the window, divide them up into frames, render each frame, and send each frame to QuickTime for encoding into a movie.

I created the following cfdg file:

Code: Select all

startshape foo

rule foo {
	SQUARE { s 0.7071 r 46 }
	foo [ x 0.5 s 1.001 x 0.5 r 2 ]
} 
and ran it until Context Free halted with the 'A shape got too big' error. I was able to save an animation from this.

Context Free stores shape information in single-precision floats so that lots of shapes can fit in memory. When one of the floats over-flows Context Free stops with the 'A shape got too big' error. I think Context Free 1.2 stored the shape info in double precision floats. You could modify shape.h/cpp to use double precision floats.

A hack that you could try to get more out of single precision floats is to pre-scale your design very small so that you are able to use more of the single precision float exponent range. Right now you are only using half of the exponent range. But with code like this:

Code: Select all

startshape foo2

rule foo {
	SQUARE { s 0.7071 r 46 }
	foo [ x 0.5 s 1.001 x 0.5 r 2 ]
}

rule foo2 {
	foo { s 0.0000000000000000000000000000000000000000000000000000000000000000001 }
}
you could use more.

dextroc
Posts: 2
Joined: Tue Feb 27, 2007 4:45 pm

Post by dextroc »

But is there a chance of disabling the "shape got to big" thing? Because I wanted the process of this to be animated (did in v.1.2):
Image

Instead I get this (same thing copied over to v.2):
Image

The latter is much more dull in the animation part, as you can imagine...

Why does it go so much simpler, btw? Are the versions so very, very different?

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

Post by MtnViewJohn »

Ah ha! There is one big difference between 1.2 vs. 2.0 that is hard to notice with designs that always shrink, but is very obvious with designs that always grow. In general when Context Free has many pending shape expansions to choose from it wants to choose the largest shape first. CF v1.2 stored pending shape expansions in a queue but sorted them by size every once in a while. CF v2.0 stores pending shape expansions in a sorted tree, so it always chooses the largest pending shape to expand.

Your always-expanding designs depend on the v1.2 behavior to choose shapes other than the largest shape to expand. But CF v2.0 never does this so your design doesn't look right. What you need is a switch that makes CF 2.0 choose the smallest pending shape expansion instead of the largest. Getting rid of 'shape got too big' won't help at all and is a red herring. You need a tweak to the basic algorithm.

jeremydouglass
Posts: 17
Joined: Fri Mar 30, 2007 9:10 pm

Smallest-first rendering - likely to add?

Post by jeremydouglass »

What you need is a switch that makes CF 2.0 choose the smallest pending shape expansion instead of the largest. Getting rid of 'shape got too big' won't help at all and is a red herring. You need a tweak to the basic algorithm.
Is a smallest-first rendering switch / directive likely in some future version of CF? Or is this not a direction the current developers are interested in?

Post Reply