Grammars

Before moving into grammatical generation of elements, there are important questions to answer   Should the grammar generate floors or columns?  Should it be context sensitive?  SHould pattern conflicts between adjacent floor or columns be resolved in the simulated annealing step (by the way, I'll be using simulated annealing)?
For now the start symbol with generate a ground floor and either a set of rows or columns.  By supporting both randomly there should be different emergent patterns to widen the variety of buildings generated.  The basics of the grammatical approach should not be too complicated.  Each symbol with evolve randomly into one of its descendants and then branching string will be terminated then the row or column has run out of the respective dimension on the building.  Here setting width and height as floats rather than a fixed number of floors will work better.

As part of the simulated annealing step I am considering a unordered "element soup" approach incase the user specifies elements that span multiple floors wants an element of out of normal alignment.  Pending better understanding of how the annealing step works this idea will be reviewed.

Non Uniform Scale

When I say non uniform scale I am not referring to the different axes having different scale factors, I mean scaling along a single axis non uniformly.  Towards that end I have added to my definition of an element (door, window, etc.) optional anchor points.  Given a target value, anything before the lower anchor point on a given axis is left in place, anything after is translated so that the furthest point (bounding box maximum) reaches the target, and anything in the middle gets LERPed along.

These elements have kept their original thin frames but have still grown to fill the target spaces defined by floor height and given (or default) widths.  However, not all of these are supposed to be of the full floor height according to the configuration file (unchanged since last post).  The next step is to let them rest at the base of the floor and move only the points within epsilon error of the top bounding box up to fill the remaining height.

Here windows with locked aspect ratios remain square as modeled and their top points fill in vertically.  The next mini-feature will be justification.  I want to be able to lift elements off of the floor baseline and then fill downwards as needed.

Now with content!

It turns out AMPL is definitely overkill for the majority of this project.  It may still be useful in the future to resolving conflicting elements when multiple content generation methods are working at once, but for now direct code will work better.  Having moved into C++ is was relatively simple to get test geometry distributing according to a user supplied configuration file.  Currently the program reads in a configuration file and library of elements and the produces a single composite OBJ file from instances of the elements following the rules in the configuration file.  My current visualization strategy is to drop it into Maya.  Example time!

These two facades were produced by altering the proportions of the bottom right door.  On the left the width is unconstrained, so it stays narrow and a second door fits.  On the right the door is locked to a 2:3 ration and the second door no longer fits.  Lets look at the file with the change in indicated:

GLobals:
    output test.obj
    width 10
    depth 3
    type facade
    floors 2 height 3
    style test
end
Floor 0:
    element door lockAspect
    element wall width .5
    element window width 2
    element wall
    element door lockAspect aspect .6666
    element wall
    element door
end
Floor 1:
    height 2
    element wall
    element window width
    element wall width 5
    element window width 
end
floor 2:
    element wall width 3
    element window
    element wall
    element window width 5
end

There are a few stability things going on here.  The global number of floors is overridden by the definition of another floor, later there should be tools for selecting which floors to use or repeat.  Floor 1 is overriding the global floor height just to prove that it works.  Additionally, each element can optionally set fixed width, height, aspect ratio  locked default aspect, etc.  All of those values have defaults and if left unset have logic to  adjust them to the building's needs.  Any elements that does not fit in the building width gets ignored and any leftover space gets filled with blank wall.

It is a personal goal to make as many arguments and constraints optional as possible to leave this system as flexible as possible.  Next up, filling in those awkward gaps around short elements and getting nonuniform scaling to that bigger elements don't have thicker frames (also maybe vertical alignment options).

Mini update: Doric Column

Given the footprint dimensions (X,Y) I can now compute the height (Z), base diameter (baseD), and top diameter (top) of a Doric Column.  Using the same relations it is equally easy to compute the area and diameters from the desired height.

Sample output:

21 iterations, objective 96000
Nonlin evals: obj = 25, grad = 24, constrs = 25, Jac = 24.
X = 20
Y = 30
Z = 160

baseD = 20
topD = 16

To kick things off I'll be experimenting with AMPL (A Modeling Language for Mathematical Programming). So far I have discovered that the solver I am using have some oddities when I allow variables to be too small (less than .01) but if I pick the right totally arbitrary modeling units I should be fine.  Heres the fun part: what to look for next.  The first test will be to solve the proportions of a doric column from its radius.  The next test is to compute the various sizes of the largest Parthenon that will fit on a given footprint.