• Highly interactive
• Climbing the ladder of abstraction

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

1. Add a relatively precise hitbox to select LSystem for modification
2. Save and load L-system models
3. Add a more complex GUI (classic with a main menu bar and right-click) and polish it
4. Add genetic algorithm or constraint-based algorithm for new LSystem generation

• LSystemView copies does not all update themselves
• Copy operations on LSystemView (and others) breaks because of Observable (id counter)

• Optimization 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).
  • Cache multi-iteration production rules (very good for execution time but bad for memory consumption)
  • Use raw OpenGL to reduce the size of vertices (no texcoord for example)
  • Use `sqrt` instead of `cos` and `sin` for angles
• Bugs
  • Correct floating point errors when using big number of iterations
  • Correct zoom level and drag behaviour when resizing window

• 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

• Static analysis (Coverity?)
• Formal documentation (Doxygen?)
• Automatic cross-compiling?
• Automatic on-screen serialization?

• Huge literature on the subject and extremely developed existing software. What does this project bring?

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).

Procedural content generation: L-Systems (by Rabidgremlin)

The Algorithmic Beauty of Plants

/r/lsystem

Job Talle – Lindermayer systems