Procedural Generation Experiments
What is this?
This application is a tool to create and paint L-System in a fully interactive and dynamic way.
“But,” you’ll say, “why yet another app for L-System? There’s a lot of them, and it gets old quickly…”
Thanks for asking the question! Here’s why and how this app is different:
- Fully-interactive: every change done through the interface is immediately visible on the fractal.
- Rich system of painting: there’s a lot of way to paint the tree thanks to painters: linearly, randomly, according to the branches, etc… Everything with arbitrary gradient. And you can have nested painters, for maximum control.
- Saving and Loading: the L-Systems can be saved and loaded. Around 40 of them are present in the saves.zip file, please take a look!
- Exporting: you can export the trees a .png files. Huge png files, according to you GPU, like 16 or 32 kilo pixels images!
- Fast: The app is in C++, so it is fast enough for real-time interactive “medium-size” L-Systems. Medium-size meaning thousands of branches! You can of course go bigger, but your RAM and CPU may die…
- (Simple) L-systems
- (Simple) Turtle interpretation
- Static GUI to display parameters
- Dynamic GUIs to interact with the parameters
- Basic and necessary user interactions (mouse dragging, adding, removing, copy-pasting)
- Saving and loading LSystems to and from files
- Complete system of colors
- BIG REFACTORING
- Complete test suite
- Remove a maximum of code smells
- Refactor old code
- Add automation:
- Loading file from command-line
- Generating image(s) from command-line
- Adding a second/alternative layer to generate save files without hacking the polymorphism
- Make the generated vertices pretty (growth, visual effects) (example in dev.time and dev.width)
- Growth as the turtle order, recursion order, …
- Rectangle of different widths for recursion
- Extend the turtle interpretation
- Angle jitter
- Color Palette
- Invisible lines
- Add genetic algorithm or constraint-based algorithm for new LSystem generation
- Extend the L-System
- Parametric L-System
- Context-sensitive L-System
- Stochastic L-System
- Parameters for each interpretation order (step for go_forward, delta_angle for turn_*)
This project use Semantic Versioning in a slightly different way. This is an application, so the internal API does not matter and may change at anytime. However, the save files are subject to this versionning. Patch version increment means that the old version can open the new save files. Minor version increment means the old version can’t open the new saves files, but the new version can open the old ones. Major version increment means that the saves files are not compatible at all. I will try to stay in 1.y.z as long as it is reasonable.
Make sure you have SFML installed, a C++17 compiler (with
std::filesystem support), and make.
make optimized :).
Other make recipees are documented in the Makefile.
There is now a CMakeLists file. It is for now quite minimal and is only used to compile the main program without the tests.
- My environment: debian sid chroot
- SFML / 2.5.1 / Website / installed from packages /
- googletest / 1.9.0 / Github Repository / installed from packages
- dear imgui, / 1.71 WIP / Github Repository / installed from repo’s release / included in the repo
- imgui-sfml / Github Repository / installed via the instructions from the README.org of the repository / included in the repo with patches
- GSL (Guidelines Support Library) / 2018-05-21 / Github Repository / cloned from the repository / included in the repo
- cereal / 1.2.2 / Website / downloaded from the website / included in the repo
- Coding rule: Try to respect ISO C++ Core Guidelines and some
clang-tidyrules (see Makefile)
- Format: Using
clang-formatto have a consistent formatting (see .clang-format)
CMakeand C++17 for simply compiling,
- Testing suite: googletest
The dev branch is where the main line of work is conducted, a commit in this branch may not compile, the application may not behave properly, the tests may not pass, and the code may not be tested, or documented. The master branch is assured to compile, the application works as intended (except for known bugs), all the test passes, and the code is documented. However, the features may not be complete.
- The API is not stable (and will probably never be, as this is a software and not a library)
Completing the framework?
- Static analysis (Coverity?)
- Formal documentation (Doxygen?)
- Automatic cross-compiling?