Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Real time render with SFML #107

Open
wants to merge 62 commits into
base: main
Choose a base branch
from

Conversation

ilyabrilev
Copy link

Hi, @davidrmiller. Thank you for this awesome repository. I've created a fork that might be worth checking out. To get the glimpse on how it looks like, you can check screenshot.png in the root directory.

The main idea is to render simulation in real time rather than in the form of video files. With real time render simulation feels more alive, debugging is easier, and it opens whole lot more possibilities to observe and interact with the simulation. I've also tried to preserve existing functionality, so my PR has no innovative ideas, it's almost pure cosmetic that can be turned of.

Here is a brief list of changes:

  • Added a new output using SFML which renders individuals, challenge criterias and barriers in real-time with the ability to drag simulation (LMB), zoom in/out (scroll), and select indiv (LMB)
  • Added UI to watch and control simulation with TGUI library. Here is most notible controls:
    • pause/resume button, pause at start/end of generation buttons
    • component to slow or increase speed of simulation
    • components for changing some settings
    • button to restart the simulation
    • button to save selected indiv's net to svg
    • button to show indivs who would pass survival criteria if simulation would end now
  • Added the ability to save (manual or auto) and load simulations with "cereal" serialization library

But first I've done some refactoring to prevent codebase from bloating because of the amount of additional files and to make it more suitable to the new flow.

  • In simulator.cpp the entry point (simulator function) is used for top-level initialization and main application loop. Main simulation loop was extracted into new simulate function.
  • New directory userio is grouping together everything related to input and output. Class UserIO is an entry point. It is called at specific points of simulation life cycle and passes it to SFMLUserIO and/or ImageWriter depending on which were enabled at the construction of UserIO. ImageWriter has not undergone any changes.
  • SFMLUserIO is the main class for real life render. Display loop and event handling are done in this class. It also includes main window, view, all custom display components and child windows. All custom components are stored in sfmlComponents directory and created by SFMLUserIO with a heavy use of callback functions. Responsibility of custom components is to display UI, hey don't usually interact with simulation logic directly.
  • survivalCriteria directory is where all challenges logic placed. It contains SurvivalCriteriaManager - a class that other parts of application are interacting with, and SurvivalCriteria successor classes that handles if certain indiv passes a criteria as well as displaying the criteria. The idea behind splitting criterias into dedicated classes was to make creating/disabling/enabling new challenges as easy as possible.
  • ai directory contains everything related to genomes, indivs, signals, etc. No major changes here
  • utils contains logic that not directly related to simulation, like: analysis, profiling tool, random number generator, and save/load system. save/load system uses cereal library which under the hood calls serialize function added for Params, Peeps and Indiv. Cereal library is located inside include library.
  • All output files now go into Output directory. This includes:
    • Images for indiv's net
    • Logs
    • Profiling results
    • Save files of previous simulations

Application was tested on Linux Mint 21.3

New requirements are:

My solution is far from being perfect. UI needs more polishing, there are not enough space for all settings and buttons. Performance was not a first priority, so there is probably a lot that can be done on that front. Building inside a docker container also stopped working, I assume because it doesn't support SFML.

ilyabrilev and others added 30 commits May 23, 2024 10:29
view refactoring (full sfml support)
Multithreading fix and refactoring
binary saves and autosave checkbox
StopAtStart and StopAtEnd buttons
@davidrmiller
Copy link
Owner

@ilyabrilev, this is awesome. Very nice improvements. I'm going to decline pulling your work into this repo only because I'm trying to transition it into maintenance-only mode. Instead, I've added a shout-out and a link to your fork in the README.md file (if you'd like that reference worded any differently, let me know). Thanks for your impressive work on this.

@ilyabrilev
Copy link
Author

That is ideal, thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants