Procedural Closures II

I now have enough of the four elements described in the last post implemented, to try out the dynamic hierarchical detail generation described.  Here's a (rather extreme) test case in action:

Menger Sponge - extreme subdivision test case

Here you can see successive sub-procedure expansions being made as the camera approaches the model.  Apart from the complexity involved in splitting up the space into 27 parts and adding 20 sub- cubes each time, the procedures - being recursive - are fairly simple.  This test case rapidly runs out of memory; a) because the object complexity escalates by a factor 20 times with each depth level, but also because b) I don’t recycle generated blocks yet. :)

After playing with it for a while and trying to build more conventional objects this way (house/street, simple landscape), I've decided that my approach to the authoring of them leaves a lot to be desired and will have to change.  To summarise the process, it works in the following way:

1. Build a hierarchy of procedures to describe your object, parameterised by (at least) the space it is to occupy and the detail level required, and with a secondary geometry output for capture. Each sub-procedure should be parameterised in the same way where possible. 
2. Procedures suitable for capturing (i.e meeting some criteria) are explicitly marked as such in the editor by selecting which inputs and outputs are to be assigned each meaning required (above).

 My main gripe with this process is the amount of extra mess this introduces when building procedural models.  Secondary (and somewhat related) is the fact that it is proving very hard to explain how to author models in this way.  It is just too explicit, too manual if you like.  I need a better way, and it needs to be as automatic as possible. 

I have been hypothesising that it is possible to gather information about a procedural hierarchy as it is being synthesised and perform an analysis of the structure such that suitable capture points can then be extracted and kept for subsequent detail generation automatically.  To help better understand the problem space, i.e. what exactly does the synthesis process look like, I decided to get Apparance to spit out enough information to visualise the process.  This would then allow me to browse the evaluation tree, looking for patterns, surprises, and insight into the rules that might be used to extract what was needed.

Visualising data you say. Trees you say. Well, a tweet from a friend of mine reminded me of GraphViz which I'd seen used to analyse large asset database dependency graphs in the past but not had cause to investigate myself…  a quick download, documentation read, and 'hello world' graph and I was ready to give it a go.  In a couple of evenings I'd got the evaluation tree for a test house displayed nicely.

House synthesis graph (click to enlarge)

 Salient features you can see here are: 

• Procedures are shown as boxes, operators as plain text, each with, any sub-procedure/operator evaluations at the end of arrows heading to the right. 
• Branches that yield geometry are solid, dotted branches are for any other types of value. 
• Branches that lead to at least one procedure are black, those that only lead to operators are grey. 
• You can see operators (or procedures) that appear to be missing further evaluations where those evaluations have already been performed by an earlier evaluation and are effectively cached. 
• Procedures that contain both procedures and operators that generate geometry are the lowest point that can be captured since operators aren't designed to be captured (as they won't sub-divide).  I have (manually) marked such procedures in red.
• It is clear that this house structure (as it stands) isn't best suited for sub-division as there are only a few suitable capture candidates high up the synthesis tree.

Initial thoughts lead me along the following lines:

1. It should be possible to evaluate and automatically capture procedures. 
2. Some means of hinting at 'bad' structure should be presented in the tools to guide model development. 
3. There may be more rules to be added later.
4. Improvements in the tools can be made to aid the construction process, for example: quick sub-procedure creation from selected elements.

Anyway, I've waffled on for quite long enough.  I shall endeavour to work on this.

Next time I'd like to talk about 'detail'; what it means and how to quantify it.