As you can see I ended up devising a new language for expressing the architecture grammars. If you get the full image above you should be able to read the code. Two rules make this very simple test.
This is a dramatic reversal on an earlier post. If you don't remember about this, my initial approach was I would never need a custom language for architecture grammars, that being the only user of this system I could do fine with so-called fluent interfaces in C++. Many commented back then I would have to bite the bullet and write a custom parser. They were right. It has saved me time, also the new language is quite powerful. I will introduce it later in a future post.
Neat! Your example code you have shown mentions 'romanesque_column_[etc]' models, are they also described in this same code, but in a different file?
ReplyDeleteThey are additional files, but they are not source code. They are the 3 polygonal models that end up instanced many times in this example.
DeleteOut of curiosity: what framework are you using for the GUI of your toolchain?
ReplyDeleteI'm using .NET from managed C++ for the UI. Preview rendering and generation happens in a traditional non-managed DLL. I found managed code to be quite slow, so I use it only for the UI. Any serious work is offloaded to the non-managed C++ or the farm.
DeleteAs you're rolling your own version of L-Systems, you might be interested in a few ideas from XL (spec), a ridiculously powerful language for L-Systems (and generally transforming and querying graphs) developed at our institute. They use it to model ecosystems, for example by simulating light filtered through trees guiding the growth of plants on the ground.
ReplyDeleteThanks, I will check it out tonight.
Delete