OpenGL Particle simulation

  • PalowPower
    24th Dec 2021 Member 1 Permalink

    Hey,

    I saw a few Particle Simulations online that use OpenGL. Wouldn't it make more sense using Opengl for TPT simulation? And would it even be possible?

     

    For Example: Faultz/Newtonian-Particle-Simulator: C# OpenGL Particle Simulation, Real-Time GPU accelerated (github.com)

     

    Even with 10 Million Particles, the Simulation ran with about 500FPS. (On a RTX 3080 Ti with Satisfactory open in background) 

     

    I'm not entirely sure if it would even be possible let TPT run on OpenGL and if it would be even possible since I'm not really familiar with OpenGL.

  • No_one
    6th Feb 2022 Member 0 Permalink

    Short answer: It'll be nearly as fast as these simulations you mentioned, but this is nearly impossible.
    Currently TPT is written in c++. Every element has it's own hardcoded behaviour, so you have to rewrite every element. Also it's impossible to run all simulation aspects (like pressure-particle coupled interaction) on gpu. And the last point, pushing down your suggestion is that TPT is actually gpu intensive app. Just compare Fancy display with Nothing one, for me it drops fps nearly by 2 times with 100000 particles.
    As I know there is a possibility to multithread TPT, but devs say it is as impossible as gpu computing.

  • upsetkiller
    24th Mar 2022 Member 0 Permalink

    PalowPower:

    Hey,

    I saw a few Particle Simulations online that use OpenGL. Wouldn't it make more sense using Opengl for TPT simulation? And would it even be possible?

     

    For Example: Faultz/Newtonian-Particle-Simulator: C# OpenGL Particle Simulation, Real-Time GPU accelerated (github.com)

     

    Even with 10 Million Particles, the Simulation ran with about 500FPS. (On a RTX 3080 Ti with Satisfactory open in background) 

     

    I'm not entirely sure if it would even be possible let TPT run on OpenGL and if it would be even possible since I'm not really familiar with OpenGL.

     

    the devs are lazy, as you said there are PLENTY of GPU or CPU multithreaded particle acceleration demos out there, hell even amd used TPT and ported most functions to openCL and sped up everything orders of magnitudes many years ago and showed it to display the power of its server cpus, its widely available on youtube to watch. yet these people keep claiming its "its impossible" to do something already done a decade ago by amd and being done in spades by other people like the one you linked and many others like these below


    https://www.youtube.com/watch?v=7PAiCinmP9Y      look at this, amd showcased tpt and made it speed up several times over lol, this alone busts any claim the current developers make , also the description says they did not do a damn thing to the application for this speed up, this was 12 years ago , whats stopping the current dev from doing the same? 


    https://www.opensourceagenda.com/projects/newtonian-particle-simulator

     

    https://github.com/BoyBaykiller/Newtonian-Particle-Simulator

     

    https://www.youtube.com/watch?v=NhnoNYqIhTI

     

    Edited 2 times by upsetkiller. Last: 24th Mar 2022
  • LBPHacker
    24th Mar 2022 Developer 2 Permalink
    https://www.youtube.com/watch?v=7PAiCinmP9Y look at this, amd showcased tpt and made it speed up several times over lol, this alone busts any claim the current developers make , also the description says they did not do a damn thing to the application for this speed up, this was 12 years ago , whats stopping the current dev from doing the same?

    The description says "[...] with OpenCL without making changes to the application." Indeed, once you have rewritten TPT to OpenCL, you can scale some of its features well across multiple compute nodes. You have also stripped off a number of important features, oops.


    Same issue. This is solving problems that are different from the ones TPT tackles, with solutions that are different from the ones TPT provides. Apples to oranges comparison. As an example, note how it lacks any form of collision.

    TPT has been used at some point as an AMD demo app, exactly for showcasing the kinds of things presented in these videos. It stopped being an AMD demo app more than 10 years ago, and has since gained many features, most of which either do not scale at all to multiple compute nodes, or which scale well at working sets much greater than the 612x384 simulation TPT is.

    Edit: the text editor is making a fool out of me, hold on. Fixed.
    Edited 3 times by LBPHacker. Last: 24th Mar 2022
  • upsetkiller
    25th Mar 2022 Member 0 Permalink

    @LBPHacker (View Post)

     

    you can clearly see in the demo that particles are actually interacting with each other , pressure waves are bouncing off the wall, so are fire and other particles in the demo by amd, and regardless that alone is a huge speedup. nothing is impossible here, thats a huge claim to make when it comes to programming, the only reason this has not happened is because of a couple or all of the following things, 1: not enough skillset with the current developer, 2: not enough motivation, or both. its really as simple as that, otherwise there would have been at least a start on it. but they should say it as it is, we don't want to do it , instead of telling people whats possible and whats not when amd did it 12 years ago, and they have no way of refuting that it worked or not regardless if a few features were missing, in what was quite possibly a few days worth of job on amds end

    Edited once by upsetkiller. Last: 25th Mar 2022
  • LBPHacker
    25th Mar 2022 Developer 3 Permalink
    you can clearly see in the demo that particles are actually interacting with each other , pressure waves are bouncing off the wall, so are fire and other particles in the demo by amd, and regardless that alone is a huge speedup.

    The demo footage is absolute oatmeal in terms of quality, so there is no way for me to discern individual particle interactions. The interactions I am seeing can be classified into two categories:

    1) Environmental reactions, such as those that rely on ambient heat and pressure, whose simulation can be parallelized easily. One of them, gravity, which is by far the most computationally intensive one, already runs on its own thread. Sadly, these features also happen to be what take the least time to simulate right now.

    2) Interactions of solids with non-solids, wherein solids prevent the movement of non-solids. While there are models for this which parallelize well, they are significantly simpler than what TPT currently has, which also handles collisions between non-solids. I see no such collisions between non-solids in the video, and that that is not simply a result of my not being sufficiently sharp-eyed is evidenced by the fact that the patterns the waves of particles make look exactly like the ones you get when you play with EHOLE (a type of wall) in modern TPT, which disables particle collisions inside itself.

    This again proves the apples to oranges nature of the comparison. Anyway, if you are unsatisfied with my response, feel free to hop into the #powder channel on Libera where you can talk with Skylark (when he is online), a former AMD employee and designer of the original TPT, and interrogate him about the various problems that that specific AMD demo had, some of which would make it unusable today if you expected the feature set of modern TPT.

    nothing is impossible here, thats a huge claim to make when it comes to programming,

    Please decide whether you think it is a huge claim or an invalid one; the way you worded it makes it difficult to tell. Since "huge" is what is correct, I will be assuming that that is what you meant.

    The fact that you are unable to solve a problem does not mean it cannot be solved, merely that you do not have a solution. In some cases, you can prove something to be impossible to do, but nobody has done that with the elusive "parallel TPT" problem yet. With this problem, we are currently content with the next best thing, which is the simple empirical result of "nobody has managed to pull it off for over a decade".

    the only reason this has not happened is because of a couple or all of the following things, 1: not enough skillset with the current developer, 2: not enough motivation, or both. its really as simple as that, otherwise there would have been at least a start on it.

    Regarding your proposed reasons as to why TPT has not yet been massively parallelized yet, yes, I agree to the possibility that we might be having skill issues. None of us are the AMD employees behind the video, after all, right?

    While there is not much you can do to fix that, the great thing about TPT is that it is a GPLv3 project, which, among other things, means that if someone comes along at some point with the solution to the "parallel TPT" problem, they can take the codebase and contribute their solution easily. In fact, that is exactly what we do; really the only thing that differentiates us from other contributors is the number of commits.

    That nobody has solved this problem in a decade despite the project being open-source sort of proves my point further. I hope this does not mean that the portion of the programmer world that knows about TPT is also unskilled and unmotivated, so if you know anyone willing to solve the problem, please send them our way. It is merely a skill and/or a motivation issue, after all.

    That said, trying to prove that apples are possible by showcasing oranges does not really work. Is it possible to get what you see on the video? Yes. Would it actually make for a usable TPT client? No. Would it be compatible with many years of existing saves? No. We like compatibility a lot, which is why you can still load saves made in decade-old versions.

    but they should say it as it is, we don't want to do it ,instead of telling people whats possible and whats not

    We do want to do it D: That is a false dichotomy, implying that the only two possibilities are that it is impossible to do and that it is possible but we do not want to do it. You are glossing over the option where it is possible and we do want to do it.

    when amd did it 12 years ago,

    They did something different from what we want to do.

    and they have no way of refuting that it worked or not

    We are also not trying to refute anything regarding what they did, because it is irrelevant, see above.

    regardless if a few features were missing,

    That is exactly where you are missing the point.

    in what was quite possibly a few days worth of job on amds end

    And that is where AMD employees beat us in the motivation department, in addition to having beaten us in skill a few paragraphs earlier. You see, they are employees.