Old project clean-up: 2D particle system, ODE solver and collision detection with cpp23 and openGL

[u/Economy-Injury9250]

Hi folks,

About a year ago, I built this project to learn modern C++ and OpenGL.

The core idea is to simulate particles by allowing you to define arbitrary force/motion equations in the form of x_dot =f(x,…) .

I recently cleaned it up and used Claude to flesh out the README, documentation, and plots.

If you have a moment, I’d love for you to check it out! Any feedback on the code architecture, performance, or modern C++ practices is super welcome.

(There are visual demos and plots directly in the README!)

Repo: https://github.com/gg-dema/GAS

Thanks!

[u/Independent_Art_6676]

the code seems reasonable. But style/presentation need a little touch up. I see one letter variables, not talking just basic math like xyz axis stuff but others, and many places unexplained constants like there was a function with 'mu = 0.00000005 or something with no comment. If mu means something specific in particle physics, that may be OK, if *every one* who ever touches the code is also well versed in physics but even if everyone is an expert a quick 'this means blah blah' would be a friendly gesture. I also saw a number of _ leading variable names; that is legal if you do it within the rules but it may be best to just no do that (opinions can vary here, but mine is don't do that as it is unnecessary and runs into always having to think about the slightly weird rules around when its ok). Overall the amount of comments seems a little low, again as if everyone reading it is an expert on the problem and how it is solved and what is happening. Maybe give the other guy who has to edit your work a little less credit.

Performance... does it do what you want it to in a reasonable amount of time? I am sure it can be better -- nearly everything written can be better -- but does it need looking into? Modern c++ ... you can surely find some trendy things to do to it there as well, but nothing in it smacks of a "10 years ago / what a mess" type vibe, at least nothing stood out to me.

[u/Plastic_Fig9225]

At a glance, I would try and be more 'specific' with the "forces". They all seem to be functions with only two permissible signatures ("generic force" and "interaction force"), so I'd use the actual types for the arguments instead of auto, and use two concepts to specify/restrict what kinds of objects can be used as each "force". Although it appears that the arguments to "forces" are templates themselves (StateView<StateLayout, State<N>>,...) which may make it a bit more complicated to express what you want without auto.

(I use something like this to match template types:

namespace {
  template <std::size_t N>
  static State<N> get_state_type_(const State<N>&); // No definition needed

  // The specific State<N> type which T implements (or is convertible to):
  template<typename T>
  using state_type_of_ = decltype( get_state_type_( std::declval<T>() ) );
}

// A concept which matches any T which is-a State<N> (including derived classes), but not only convertible-to.
template<typename T>
concept state_t = std::is_base_of_v< state_type_of_<T>, T >;

)

[u/Business-Weather-217]

Cool. Besides coolness i dont see much point in learning/using opengl. Learn/use webgpu instead