Context Free Forums and Gallery

TorfusPolymorphus wrote:Since version 2.2 there's the size command. It works like the tile command, but instead of wrapping around it simply crops the image to the given region. This should help if you run out of memory during drawing, although I guess all the shapes themselves have to be created nevertheless (even if they're not drawn).

hereld wrote:

TorfusPolymorphus wrote:Since version 2.2 there's the size command. It works like the tile command, but instead of wrapping around it simply crops the image to the given region. This should help if you run out of memory during drawing, although I guess all the shapes themselves have to be created nevertheless (even if they're not drawn).

hmm.... very promising. but it looks like it doesn't give a sub-section, but rather focuses on centering as far as i can tell. would like to create the shapes for 100K x 100K and then render only one of the hundred 10K x 10K sub-images. these could then be stitched back together after all hundred png files were created.

hereld wrote:hmm.... very promising. but it looks like it doesn't give a sub-section, but rather focuses on centering as far as i can tell.

startshape start

size [ s .5 x .5 y .5 ]

rule start {
	CIRCLE { sat 1 b 1 }
}

size [ s .5 x .5 y .5 ]

TorfusPolymorphus wrote:
I do think it does what you need. Say we start with a scene like this:

Code: Select all

startshape start

size [ s .5 x .5 y .5 ]

rule start {
	CIRCLE { sat 1 b 1 }
}

Then adding

Code: Select all

size [ s .5 x .5 y .5 ]

will render the lower left quarter of the circle. You get the other quarters by using all combinations of +-.5 for x and y. Of course you can get smaller subsections by using a smaller scale.

Is this what you're looking for?

MtnViewJohn wrote:The size feature isn't really designed for this kind of output. You might get it to work but I bet that there would be artifacts at all of the edges. What is really needed is a new drawing canvas type that claims to be 100k x 100k pixels to the rendering engine but actually draws to a 10k x 10k subset. That way the image pieces would stitch together perfectly.

MtnViewJohn wrote:The way Context Free works is that all of the shapes are calculated in a unitless coordinate space. As it generates each shape Context Free keeps track of the bounding box in this unitless coordinate space that contains all of the shapes. Then Context Free streams all of the shapes to a drawing canvas, but first it calculates a scaling and shifting affine transform that maps the bounding box in the unitless space to the bitmap with pixel units.

The size command tells Context Free to not bother calculating the bounding box. Instead the bounding box for drawing is specified by the size command. But this user-specified bounding box is in the unitless coordinate space, not the pixel coordinate space of the drawing canvas bitmap. The edge of the bounding box will almost certainly not align exactly with a pixel boundary. So I'm guessing that when the images are stitched together the edges will be noticeable.

Another issue that could cause edge artifacts is that small shapes that overlap the edges may be drawn on one side of the edge but get culled from the drawing list on the other side.

These two reasons are why I think it is better to implement this affect by subdividing the drawing operations in the pixel coordinate space.