Procedural Generation Experiments

Philosophy

Highly interactive
Climbing the ladder of abstraction

Main Roadmap

Optimize L-System and Turtle execution time and memory consumption With the current algorithm, execution time and memory consumption are exponential. Memory consumption is the biggest factor, as several GB can be allocated easily (from 16 iterations).
Make an integrated and interactive GUI with = dear imgui, =
Save and load L-system models
Vizualize the turtle moving

Implemented

(Simple) L-systems
(Simple) Turtle interpretation
Static GUI to display parameters
Dynamic GUIs to interact with the parameters

Optimization

Ideas:

Cache L-System (excellent for multiple execution time but awful for memory consumption)
Cache multi-iteration production rules (very good for execution time but bad for memory consumption)

Memory allocation with Valgrind (2017-09-17 Epholys)

valgrind --tool\=massif --time-unit\=B --peak-inaccuracy=0.1

Memory usage is directly linked to the size of the L-Systems calculated. These sizes grow exponentialy, so does the memory. As an example, with a simple L-System and 16 iterations, the resulting string is composed of tens of million of symbols. Saving these symbols and the 20-bytes-long vertices associated takes at least hundreds of MB in memory. Moreover, during the execution of logo::computes_vertices, we use a std::vector as data structure. Its allocation strategy (in g++ and MSVC) is to multiply the capacity by a number. As a consequence, this vector is at most “factor” times too large. In our case of hundreds of MB, it can be a serious toll. Fortunately, this vector is truncated when returned by the function.

I don’t see an obvious way to reduce memory consumption. Symbols and vertices are already very small. We could reduce the size of the aforementioned vector by reserving just enough bytes for the vertices. But that means we would have to approximate a small upper-bound of the result of the L-System and also how much of its symbols will produce a new vertex. A whole mathematical problem.

For now, I’ll do nothing: I see no reasonable case to computes and display so much iterations of a L-System. I’ll concentrate on optimizing execution time (with memory consumption in mind).

Development framework

Environment: debian stretch chroot with these development packages: g++ make git libsfml-dev googletest gdb valgrind
Dependencies:
- SFML / 2.4.1 / Website / installed from packages/
- dear imgui, / 1.5 / Github Repository / installed via release 1.5
- imgui-sfml / 2017-07-04 / Github Repository / installed via the instructions from the README.org of the repository
- googletest / 1.8.0 / Github Repository / installed from packages
- GSL (Guidelines Support Library) / 2017-06-27 / Github Repository / cloned from the repository
Coding rule: ISO C++ Core Guidelines with GSL
- Difference: Allman indentation Style
- Difference: When using ImGui ; ImGui style of coding
Compilation: make
Testing suite: googletest