Reflections?

[chris]

Has anyone thought about this reflections? There's no way to reflect something using translations and rotations.

For example, let's say you have a certain shape, half_a_heart. You could do this:

rule heart {
half_a_heart { }
half_a_heart {x -1 flip 90}
}

basically a flipped object, in the absolute sense, is one where its reflected over a line of a certain angle. It's like you flip over and start drawing on the BACK of the canvas from that point, including the children, of course, since it's context-free.

(The rotation is an unnecessary parameter, and it could be always along the y axis, actually, since you could then use rotations to get where you want.)

I'm luke warm to it, but it's a pretty natural operation, along with rotation and translation. And it can't be achieved by combining the existing operators.

From the development perspective, it seems very straightforward. It's just a question of whether people would like it or not. It's somewhat appealing to me because I feel like the three operations (rotation, translation, reflection) are an important combo in linear algebra.


Obviously it can be bypassed by just creating a cfdg file twice as large.

-cc

[Guest]

[color = black]If the operator can be applied to a called function like rotate, so the entire function were run as a reflection, that would be useful, as I've had to write almost double the code for images that involve reflections, just to handle the flip. But I don't know how easy it'd be to use reflect in terms of an entire function, like a right-branching tree, to make an entirely left-branching counterpart.

To be shorter, I'm interested, if you care to take the work to figure out how.[/color]

[MtnViewJohn]

I see a lot of CFDGs with tons of duplicated code because it generates mirror images of some shape. Authors/artists have to make sure that changes made to the left shape are also made to the right shape. Adding the flip parameter would make CFDG files shorter and easier understand and debug.

We would need to determine what order the flip transform happens with respect to rotates and translates. My guess is that we would want the flip transform to happen after the rotate.

As an aside, I think it is unfortunate that CFDG specs a fixed order for the rotate and translate transforms. If you want to do the rotate before the translate then you have to do it in two steps: rotate an intermediate shape and have the intermediate shape do the translate. Here is an example.

Code: Select all

rule Triangle {
  RotSide {}
  RotSide {r -120}
  RotSize {r 120}
}

rule RotSide {
  TriSide {y -0.1234}
}

If the author could spec the order of the transforms then they could write this.

Code: Select all

rule Triangle {
  TriSide {y -0.1234}
  TriSide {r -120 y -0.1234}
  TriSize {r 120 y -0.1234}
}

In order to be backward compatible with the current generation on CFDG files we need to be able to support the current fixed order of transforms and have a syntax to indicate that author specified transform order is needed.

Code: Select all

rule Triangle {
  TriSide {{y -0.1234}}
  TriSide {{r -120 y -0.1234}}
  TriSize {{r 120 y -0.1234}}
}

[futrelle]

This I think belongs to the class of problem that can be solved by allowing rules to push bindings on the same stack that holds the current coordinate transform.

Instead of this:

Code: Select all

startshape mirrorSpiral

rule mirrorSpiral {
	leftSpiral { }
	rightSpiral { }
}

rule leftSpiral {
	CIRCLE { }
	leftSpiral { x 1.5 s 0.9 r -20 }
}

rule rightSpiral {
	CIRCLE { }
	rightSpiral { x 1.5 s 0.9 r 20 }
}

you could have something like the following:

Code: Select all

startshape mirrorSpiral

rule mirrorSpiral {
	spiral { foo 20}
	spiral { foo -20 }
}

rule spiral {
	CIRCLE { }
	spiral { x 1.5 s 0.9 r foo }
}

[mtnviewmark]

This I think belongs to the class of problem that can be solved by allowing rules to push bindings on the same stack that holds the current coordinate transform.

Not for two reasons: 1) There is no amount of rotation, translation and scaling that equals a flip. 2) Two flips about the same axis would result in no flipping. Whereas pushing a binding of foo to -20 twice probably wouldn't.

This brings up that simply adding bindings probably isn't enough. One would need a way to declare how the binds "nest". For example, angles and distances always add, whereas scales multiply, flips are a whole other matter.

[buckyboy314]

For example, let's say you have a certain shape, half_a_heart. You could do this:

rule heart {
half_a_heart { }
half_a_heart {x -1 flip 90}
}
-cc

The 90 seems quite unnecesary, as a parameter-less flip could be combined with current rotations to enable all possible simple distortions. Also, the whole concept of a flip is unneeded. Sizing could just be extended to horizontal and vertical distortions. For example, SHAPE{xs .5 ys .9} would make an instance of SHAPE with 50% width and 90% height. HOWEVER, as opposed to simply causing an error when given a negative parametr as size currently does, a flip could simply be a negative input. Therefore SHAPE{xs -.2 ... } would simply be a shape that, during the scaling step in branch processing, would be reduced to 20% width and flipped horizontally.