Shadama: A Particle Simulation Programming Environment(tinlizzie.org)
tinlizzie.org
Shadama: A Particle Simulation Programming Environment
http://tinlizzie.org/~ohshima/shadama2/live2017/
19 comments
Oh this is really sweet! I was always in love with physics. One day when I was in high school, I saw a computer game that did projectile path simulation. Something clicked in my brain. I realized just how powerful simulations could be in validating and discovering new physics. That was the day I decided to become a computer engineer. I wish something like this was available when I was in high school. Younger me would have been absolutely delighted. :)
But it's just "particles" in 2D.
You can have much more fun with something like BPP [1] or Blender's physics modules [2].
[1] https://github.com/bullet-physics-playground/bpp
[2] https://docs.blender.org/manual/en/latest/physics/index.html
You can have much more fun with something like BPP [1] or Blender's physics modules [2].
[1] https://github.com/bullet-physics-playground/bpp
[2] https://docs.blender.org/manual/en/latest/physics/index.html
Even UE4 is really accessible as a physics playground, with PhysX 3.x, GPU particles, cloth simulation etc.
So you have for each body position at time t, mass, charge, whatever. Then you calculate the forces, acceleration and speed and finally the position, mass, charge,.... at (t+1). Rince repeat?
The problem with this strategy is that you accumulate errors and the results are a function of the floating point representation. Your universe big bang simulation might give you a steady state for floats but implode for doubles aso. Also, checkpointing your results and restarting from the persistent state might make the simulating go somewhere else (which is how Lorenz discovered chaotic systems iirc).
Anyway, proceed with caution.
The problem with this strategy is that you accumulate errors and the results are a function of the floating point representation. Your universe big bang simulation might give you a steady state for floats but implode for doubles aso. Also, checkpointing your results and restarting from the persistent state might make the simulating go somewhere else (which is how Lorenz discovered chaotic systems iirc).
Anyway, proceed with caution.
Thanks for a comment. One thing I would like to point out is that this is a programming language and does not dictate what integrator you use; you can write your own and experiment. The idea is to make that be opened up for users.
it's an improvement (iirc, it makes the error-growth linear), but does not 'fix' the problem.
The whole point of symplectic integrators is that they guarantee energy conservation (when applied to Hamiltonian systems). It takes some work (random example found by quick googling: [1]) which may not be deemed necessary if the drift produced by a naïve implementation is already small, but an insurmountable obstacle it is not.
[1] https://arxiv.org/abs/1005.1930
[1] https://arxiv.org/abs/1005.1930
iirc for a limit cycle the error will be + or - over different intervals of the cycle but the sum of the error around the cycle will be zero
I've been thinking quite a lot recently about how grass is generally made using particle systems, and while it works reasonably well, it never really matches a lawn. If you go outside and get dirty in it, you'll see two things: horizontal runners that criss -cross that then grow upwards. The more the grass is walked on, the less upward growth you have and you're generally left with the horizontal runners.
ok. I have spent way too much time thinking on this, but ever since I was writing my own engines and modellers (before 3ds max, blender and unreal engines existed), I've always expected realism of 3D to be a thing -- and to a large extent it has become that... but the 3D modelling is still taking some serious shortcuts imho, and particle systems -- although really cool -- are not really addressing realistic models of organic life, despite them being used in that way for landscapes.
So, although I encourage any and all work in this area, I hit a mental bump when I read this article, because it seems that particle systems have become too much of a thing, at least to me, and it might be hindering a next gen of organic modelling. I find it ironic that great leaps have come in material handling: modelling skin, as well as Physical Based Materials (eg Blender's new eevee renderer), but fractalish/ high poly natural organics are stuck back in the 90's. Is there someone working in this space that I've not come across perhaps?
ok. I have spent way too much time thinking on this, but ever since I was writing my own engines and modellers (before 3ds max, blender and unreal engines existed), I've always expected realism of 3D to be a thing -- and to a large extent it has become that... but the 3D modelling is still taking some serious shortcuts imho, and particle systems -- although really cool -- are not really addressing realistic models of organic life, despite them being used in that way for landscapes.
So, although I encourage any and all work in this area, I hit a mental bump when I read this article, because it seems that particle systems have become too much of a thing, at least to me, and it might be hindering a next gen of organic modelling. I find it ironic that great leaps have come in material handling: modelling skin, as well as Physical Based Materials (eg Blender's new eevee renderer), but fractalish/ high poly natural organics are stuck back in the 90's. Is there someone working in this space that I've not come across perhaps?
In general, when modelling reality (either for games or offline simulation/rendering) developers are focused on techniques that have a significant impact on the perceived realism of the result while also offering the possibility of an efficient implementation.
So PBR is widely adopted because it increases realism for little additional cost.
More advanced grass simulation would of course be possible but the cost/benefit return is debatable. Particle systems are widely used because particles are a useful abstraction for simulating all kinds of materials and because they can be efficiently solved using vector processing techniques and GPUs.
So PBR is widely adopted because it increases realism for little additional cost.
More advanced grass simulation would of course be possible but the cost/benefit return is debatable. Particle systems are widely used because particles are a useful abstraction for simulating all kinds of materials and because they can be efficiently solved using vector processing techniques and GPUs.
Reminded me a bit of the much older https://ccl.northwestern.edu/netlogo/ : a multi-agent programmable modeling environment. It also uses a multi-turtle based approach for many of its examples.
That's not a coincidence:
> The basic execution model follows the tradition of StarLogo and its "turtles and patches" abstraction.
StarLogo was an influence on NetLogo[0]:
> The NetLogo language and environment differ in many respects from MIT StarLogo's. Both languages were inspired by the original StarLogo, but were redesigned in different ways.
[0] http://ccl.northwestern.edu/netlogo/2.0.0/docs/faq.html#diff
> The basic execution model follows the tradition of StarLogo and its "turtles and patches" abstraction.
StarLogo was an influence on NetLogo[0]:
> The NetLogo language and environment differ in many respects from MIT StarLogo's. Both languages were inspired by the original StarLogo, but were redesigned in different ways.
[0] http://ccl.northwestern.edu/netlogo/2.0.0/docs/faq.html#diff
I was hoping for an environment where particles interact with each other. Which is the hard part, you generally don't want a O(n^2), you want some sort of a quadtree that will optimized the calculations.
Interesting, but I’m not sure why I’d use this over processing/p5.js augmented with a library to provide the fast compute part on an accelerator. I already do this for compute intensive things: I have a library for agent based models that I give to students that provides fast data structures and algorithms that they use from processing. I don’t see the benefit of a whole new language. The primary feature that it seems to add is live updating of the code, but I’m not convinced about that either (similar ideas have been kicked around for years in computational science contexts with respect to online tweaking/steering of models, and rarely have had any traction in practice.)
Cool stuff! I wish GPU programming was more accessible for mortals, so one could implement similar thing with any mainstream programming language as a normal library.
The ssl cert might be lapsed as this shows as insecure for me.
This is the first author.
Can you tell me which page you get the cert problem? It's been up to date and I don't see a problem.
Can you tell me which page you get the cert problem? It's been up to date and I don't see a problem.
When I follow the link in the HN post it says so in Safari