All this business with recursion vs equation got me thinking a bit, and I thought I would have a go at an egg using processing. Now for those of you happy with Bezier curves that is one way to go, but I favour the equation route in this instance, as it is relatively simple, and the placement of yolk does not require experimentation what do you think (by the way

kiplings got some

fantastic egg shapes using context free, follow the link and scroll down a bit for his chicken and eggs, far too advanced for me).

1 **void** **setup**()**{**

2 **size**(300, 400);

3 **background**(0, 0, 255);

4 **smooth**();

5 **translate**(width**/**2, height**/**3);

6 **noStroke**();

7 **beginShape**();

8 **for** (**int** angle **=** 0; angle **<** 360; angle**+****+**)**{**

9 **float** x **=** getX(angle ***** PI**/**180, 100);

10 **float** y;

11 **if** ((angle **<** 90)**|****|**(angle **>** 270))**{**

12 y **=** getY(angle ***** PI**/**180, 100, 60);

13 **}**

14 **else****{**

15 y **=** getY(angle ***** PI**/**180, 100, 10);

16 **}**

17 **vertex**(x, y);

18 **}**

19 **endShape**();

20 **fill**(224, 224, 34);

21 **ellipse**(0.0, 0.0, 150.0, 152.0);

22 **}**

23

24 **float** getY(**float** theta, **float** r, **float** k)**{**

25 **return** (k **+** r)*******cos**(theta);

26 **}**

27

28 **float** getX(**float** theta, **float** r)**{**

29 **return** r*******sin**(theta);

30 **}**

Deconstructing

kiplings chicken and egg, I came up with the following (NB: some of the rules may be spurious/ignored it is after all a hack). The result I thought was rather impressive.

1 **startshape** shape

2

3 **background****{** **b** **-**1 **}**

4

5 **rule** shape**{** egg**{** **}** **}**

6

7 **rule** mound**{**

8 **CIRCLE** **{** **s** 2 1.5 **y** **-**1 **z** **-**1**}**

9 mound **{** **s** .999 .998 .999 **b** 0.5 **h** 60**|****h** 0.03 **sat** 0.5**}**

10 **}**

11

12 **rule** egg**{**mound**{** **|****b** **-**.2 **b** .2 **y** 1 **z** 1 **s** .7 1**}**

13 **}**

Variation NVSTOK...I don't know about you, but I got to see those funky moiré fringes again (I hate to think what it looks like on a CRT monitor), does make my processing effort look rather tame.

And for a less psychedelic version, where the hue orange/yellow does more or less what I expected there is this (sports my completely revised syntax highlighting for jedit, rule/path/shape names are now all highlighted as if they were functions):-

1 **startshape **shape

2

3 **background**{ **b** **-**1 **}**

4

5 **rule** shape{ egg { **hue** 40.4 **}** **}**

6

7 **rule** mound{

8 **CIRCLE** { **s** 2 1.5 **y** **-**1 **z** **-**1 **}**

9 mound { **s** .999 .998 .999 **b** 0.01 **sat** 0.01 **}**

10 **}**

11

12 **rule** egg{ mound{ **|****b** **-**.2 **b** .2 **y** 1 **z** 1 **s** .7 1 **}**

13 **}**

Variation SBCPOVNow that I've hacked kiplings code, I would like to understand it, but the documentation is terse to say the least:-

The key bits are:-

The geometry of shapes is defined by a two dimensional affine transform which is represented internally as a matrix. No 3D then but we do have a 'z' translation.

The z-axis position determines which shape is on top when they overlap.

The z-axis position is not stored in the affine transform matrix and does not affect the shape of objects. And in the comment explaining the 3 argument size adjustment eg {

s 2 4 1} there is the following:-

The z-axis scale is not stored in the affine transform matrix and does not affect the shape of objects. Line 8 above has a 'z' translation

Line 9 above has a 'size' adjustment with 3 arguments

Line 12 has a 'z' translation