Omg thanks for reply! I think its already as much fun to play with as Universe Sandbox, I assume you've seen that. It has huge potential! Can you share what language its in or any of the code for drawing a circle? It already draws a bigger circle for larger masses, but only slightly. Does the hitbox expand with it, or is that why the effect is so minimal? The Solar System preset has coloured circles.. another idea is to have masses above 10^x draw in colour c... where x=8, c=1.. x=9, x=2, etc.. also the trails is nice, but maybe you can optimise the code by omitting it, not having to store.. 300,000 coords? but maybe have the option to draw little vector arrows for velocity as the F3 thing.. but otherwise have less code to execute and faster simulation? I would love to see some option for objects to bounce in some situation, like low speed low angle glancing blows, but merge in head on higher speed ones etc. But more urgently, and much easier - have some very very tiny "drag" factor so orbits very gradually decay.. that would help systems evolve and not remain static forever, and I think matches real life.. orbits decay over very long timescales, not just from interstellar dust but also from other effects. Any info you can share would be great, would be amazing if it could be Open Source someday, even though I suck at coding. Thanks for making and sharing it!
I am currently doing some work to allow for a config file. The calculation for the size is log e (mass) * 2.5f. I may add an option for customising this as one of the first config options.
I have now done the code for customising the log base for the size calculation, but this requires doing two log calculations per call rather than one. The sizes can be cached but in grid based mode it has to use an unordered_map to fetch some of the cached sizes which means it runs slightly slower than before. However, hopefully I will be able to make some changes to how the grid based system works, if it can be made much faster overall then the difference in the size calculation won't matter much.
← Return to project
Comments
Log in with itch.io to leave a comment.
Great program! Would be lovely to have a config file or options for how larger-mass bodies are shown, etc
Yes, I would like to add that eventually. Currently I am trying to get it to run faster with more particles.
Omg thanks for reply! I think its already as much fun to play with as Universe Sandbox, I assume you've seen that. It has huge potential! Can you share what language its in or any of the code for drawing a circle? It already draws a bigger circle for larger masses, but only slightly. Does the hitbox expand with it, or is that why the effect is so minimal? The Solar System preset has coloured circles.. another idea is to have masses above 10^x draw in colour c... where x=8, c=1.. x=9, x=2, etc.. also the trails is nice, but maybe you can optimise the code by omitting it, not having to store.. 300,000 coords? but maybe have the option to draw little vector arrows for velocity as the F3 thing.. but otherwise have less code to execute and faster simulation? I would love to see some option for objects to bounce in some situation, like low speed low angle glancing blows, but merge in head on higher speed ones etc. But more urgently, and much easier - have some very very tiny "drag" factor so orbits very gradually decay.. that would help systems evolve and not remain static forever, and I think matches real life.. orbits decay over very long timescales, not just from interstellar dust but also from other effects. Any info you can share would be great, would be amazing if it could be Open Source someday, even though I suck at coding. Thanks for making and sharing it!
The C++ code can be downloaded from https://github.com/arganoid/ParticleUniverse
I am currently doing some work to allow for a config file. The calculation for the size is log e (mass) * 2.5f. I may add an option for customising this as one of the first config options.
I have now done the code for customising the log base for the size calculation, but this requires doing two log calculations per call rather than one. The sizes can be cached but in grid based mode it has to use an unordered_map to fetch some of the cached sizes which means it runs slightly slower than before. However, hopefully I will be able to make some changes to how the grid based system works, if it can be made much faster overall then the difference in the size calculation won't matter much.