How do people go from web dev/gradle/java knowledge to build something like this.
For me, sometimes I wonder since I never did CS undergrad, I will never understand any of this no matter how many programming langauge I learn. I did dabble a bit with OPENLY, LIBGDX, GODOT, unity but to come to with cloth simulation from scratch, damn
I have felt similar, wanting to learn physics sims. I have had to learn over time to separate domains of knowledge like physics from programming tools used to ~manifest them. Especially starting with gamedev, initially it felt like there should be a natural programming idiomatic way to set up each of the major simulations like rigid bodies, cloth, springs, fluids, so the first thought I had was these sims will be naturally encoded in the language, like a fluid sim being somehow setting up a grid, then choosing some update rules per timestep. But really it is modelling a problem as real mathematics and physics, then mapping this to a language/toolset which perhaps can't naturally express it idiomatically.
There are a few algorithms like some cloth sims based on particle positions and springs, which can be coded easily, but that was misleading to me when trying to improve, I had to dig a lot more into physics and numerical analysis then mapping the problem to code, which can end up clunky and with a lot of magic numbers.
At the end of the day, it's all just maths and physics.
You didn't specifically ask about game development, but that domain is where the majority of graphics, mathematics, lighting, physics, etc, knowledge is distributed. And it can be difficult to find information solely about (e.g.) cloth simulation and other niche topics without it being coupled into game development resources.
I happened to read https://alextardif.com/LearningGraphics.html today, which might give you some pointers in various directions. https://learnopengl.com/ gets a consistently good rap, even today when there are newer APIs like Vulkan, Metal and DX12. Consider the API as 5% of the problem to solve though (less tbh, though Vulkan is proving even heavier than I was warned).
If you don't want to learn C/C++, I understand there's a large community around WebGL, so finding their subreddits and other forums could be a good starting point too.
However, again, the API and platform is really just a wrapper around the actual physics simulation (the impressive/novel part).
(Source: I'm a web dev/gradle/java developer who is once again building a game engine in their spare time after a previous attempt many years ago)
They're completely different skillsets. You just have to go from the ground up and grind to learn it all (this demo isn't that hard but generally it could take years). You probably have to unlearn a ton of stuff you adapted to when learning java/web dev.
it's not that difficult. in javascript, you represent each point in (x,y,z), give it a mass, and every frame apply gravity, maybe with some noise added. every time the particle tries to move, you use trigonometry to transmit the forces through the edges to the other points + some damping amount so it doesn't runaway. the mass determines how much each point is affected by subsequent forces.
This is seriously impressive work — simple yet mesmerizing. Really highlights how powerful Verlet integration is for creating natural, believable cloth simulations. For anyone interested, I'd also recommend checking out Jakobsen's paper from the Hitman game engine — it's a classic. Thanks for sharing this inspiring project!
What fascinates me the most is how setting a few parameters and constraints can lead to such realistic motion. It feels like a reminder that the world around us might just be a set of hidden models and forces — and our task is to discover and simulate them. Beautiful work!
These cloth simulators always feel somewhat unstable - try generating a Grid cloth, and see it start bouncing and moving randomly. Is this due to accumulating IEEE 754 floating point errors?
From what I understand it's not just floating point errors, but due to the nature of approximating continues function as simple discrete steps. Linked wikipedia article has a graph demonstrating that with large steps the error accumulates way before floating point precision is a concern.
There are different numeric integration techniques with different tradeoffs. Stuff like Eulers method, Verlet, Runge-Kutte. In some of them overall energy tends to accumulate in others it gets lost both of which is wrong. Some of the more complex ones tend to behave a bit better, but then you get into the problem whether gains from each individual step being more complex outweighs what you would get from running more iterations of simpler/faster algorithm.
I've got a demo[1] where people can play with (my interpretation of) various calculation engines, adjust variables, etc. But seeing this comment made me realise I've never heard of Verlet integration[2] before - not surprising given that I got an F in Maths (and got thrown out of Physics before I could take the exam). So ... how efficient and accurate is Verlet compared to Euler/Runge-Kutte/etc? And what other methods are out there for this sort of calculation?
Verlet integration became the go-to method for particle effects and soft surfaces back when people wrote their own game engines, mostly thanks to the paper documenting its implementation for the first Hitman game [1]. In fact, I'd say it got cargo-culted by game devs for that purpose and that purpose only, despite it being a general method and competing with others.
Would be interesting to know what integrator they use. Verlet schemes can be implemented with very little effort and they don't suffer from this issue (see e.g. the leap frog method).
But in general you would nearly always add some sort of damping mechanism, particularly for CG applications.
Energy preservation doesn't work by default in physics simulations unless you specifically code for it (e.g. by periodic explicit adjustment).
It's not only the rounding error, it's also quantisation of time and other minor errors coming from the mathematical model itself.
If the error is on the damping side, you get the real life effect of motion eventually stopping due to energy dissipation. If it's on the acceleration side you get a runaway simulation.
I've always loved this sort of cloth animation. I think the first one I saw was dissimulate's tearable cloth demo on Codepen - I can't believe they wrote that code 9 years ago!
Simulating cloth for instance with spring/damper models is quite old. Even older than robotics research on folding cloths—and it has progressed pretty far. See for a recent survey:
Can you clarify if Foldimate is still a going concern? Their Wikipedia page says they folded, but some website is trying to sell Foldimates.
As for Laundroid, 16000 is more expensive than getting the work done elsewhere.
For me, sometimes I wonder since I never did CS undergrad, I will never understand any of this no matter how many programming langauge I learn. I did dabble a bit with OPENLY, LIBGDX, GODOT, unity but to come to with cloth simulation from scratch, damn
There are a few algorithms like some cloth sims based on particle positions and springs, which can be coded easily, but that was misleading to me when trying to improve, I had to dig a lot more into physics and numerical analysis then mapping the problem to code, which can end up clunky and with a lot of magic numbers.
You didn't specifically ask about game development, but that domain is where the majority of graphics, mathematics, lighting, physics, etc, knowledge is distributed. And it can be difficult to find information solely about (e.g.) cloth simulation and other niche topics without it being coupled into game development resources.
I happened to read https://alextardif.com/LearningGraphics.html today, which might give you some pointers in various directions. https://learnopengl.com/ gets a consistently good rap, even today when there are newer APIs like Vulkan, Metal and DX12. Consider the API as 5% of the problem to solve though (less tbh, though Vulkan is proving even heavier than I was warned).
If you don't want to learn C/C++, I understand there's a large community around WebGL, so finding their subreddits and other forums could be a good starting point too.
However, again, the API and platform is really just a wrapper around the actual physics simulation (the impressive/novel part).
(Source: I'm a web dev/gradle/java developer who is once again building a game engine in their spare time after a previous attempt many years ago)
If you aren't ready for it in 3d, do it in 2d.
https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...
From what I understand it's not just floating point errors, but due to the nature of approximating continues function as simple discrete steps. Linked wikipedia article has a graph demonstrating that with large steps the error accumulates way before floating point precision is a concern.
There are different numeric integration techniques with different tradeoffs. Stuff like Eulers method, Verlet, Runge-Kutte. In some of them overall energy tends to accumulate in others it gets lost both of which is wrong. Some of the more complex ones tend to behave a bit better, but then you get into the problem whether gains from each individual step being more complex outweighs what you would get from running more iterations of simpler/faster algorithm.
[1] - https://scrawl-v8.rikweb.org.uk/demo/particles-008.html
[2] - https://en.wikipedia.org/wiki/Verlet_integration
[1]: https://www.cs.cmu.edu/afs/cs/academic/class/15462-s13/www/l...
It's not only the rounding error, it's also quantisation of time and other minor errors coming from the mathematical model itself.
If the error is on the damping side, you get the real life effect of motion eventually stopping due to energy dissipation. If it's on the acceleration side you get a runaway simulation.
https://youtu.be/wSSqx-Dh6ko
[1] - https://codepen.io/dissimulate/pen/eZxEBO
[2] - https://github.com/Dissimulate/Tearable-Cloth
It's very simple to implement a basic setup like this, and I agree that the results are super cool.
https://arxiv.org/abs/2407.01361