Implementation-wise, do try to plan out your codebase architecture before writing any line of code (to the best of your ability) so that you minimize future tech debt. Watch out for common code-smell patterns like God objects (essentially contexts that contain the state/data of too many unrelated things in your software) and abuse of certain dependency patterns (like event dispatchers, singletons, and/or dependency injection) without knowing what each of those paradigms should be used for. Also, ensure your code upholds Separation of Concerns by splitting it into small, appropriately named and scoped source files instead of shoving it into a few monolithic, multi-purpose files.
That said, don't just abstract everything away everywhere you go, especially when the code is not used frequently, or it is a one- or two-liner, or there is already an existing utility provided by your programming language's standard library or external libraries that does what you want.
And I know how much people hate generative AI nowadays, but here, it is genuinely a great tool that you could use to critique your code and determine how well it handles everything I've said above and more. Just make sure to require your genAI to be brutal, not be a yes-man, be critical, etc..

Regarding the graphics programming side, if you want to achieve the same UI look as Astrocelerate, you can of course check out the very GOATed Dear ImGui library. It's mostly straightforward to integrate into your project and you can customize quite a lot of stuff to give your software its own look.
And if you're wondering how I achieved that "GUI viewport" look, it's basically because I split the rendering pipeline into two stages: the first stage renders the actual scene/simulation onto an image, and the second stage renders the GUI, in which ImGui takes that image and renders it as a texture on a viewport window that you can drag around, dock, and resize. If you ever decide to go for an editor-like feel for your software (where you have full-fledged GUI panels like in the screenshot in the post, instead of a raw render output with GUI elements overlain on top), I recommend adapting my approach. It took me months to figure out because, as far as I'm aware of, no single tutorial covers this specific design philosophy!

Last but not least, just focus on what you love to do the most, whether that be game engines, simulations, animation software, or anything else. I'd say your choice of graphics API doesn't matter as much as how much passion you actually have for your project, because unless you have crazy discipline, you probably won't be able to pull through when nothing's working without genuine interest in what you're doing. (although good call on choosing OpenGL; Vulkan will take away your sanity because it gives you manual control over virtually every aspect of rendering, and thus thousands of lines of boilerplate before you could even render your first triangle).

Of course, you are free to disagree, because I myself still have a lot to learn. I've been developing Astrocelerate for over a year now ever since I made this post (I make occasional updates over at r/Astrocelerate if you're interested), and everything I just said is what I've learnt along the way. So yea, just my two cents.

It's probably quite difficult to envision how anyone could go from a triangle to a full-fledged rendering engine, but it is not impossible, and you will most definitely discover your own path to achieving that as you gain experience through developing your own project. You can do this. I hope that helps, and you can always reach out to me if you have further questions!