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.

>web dev/gradle/java knowledge to build something like this

Web dev (and not just in java) is dominated by "component integration" concerns, containing lots of structure but little content. Computation is delegated to libraries, and the problems more about complexity of integration (at build time) scaled distributed systems (at runtime). In contrast, writing a simulation is computationally intensive, so most of the code is content. It's homogenous where web dev is heterogenous. The problems are entirely constrained by single process performance within a time budget determined by fps.

All that means is that you can focus on one runtime. I suggest the browser, since it solves the distribution problem. Ganja[1] is perhaps the ultimate "content, not structure" simulation project. It's very strange, and lies unmaintained because it's impenetrable. Yet it works. A bit more structured is D3 who's authors have written cutting edge visulation/layout algorithms for you, for example in support of force directed graphs[2]. A more friendly way to get started would be with some variant of Processing[3], which started as a Java thing and then got ported around, including to Python and JavaScript. A word of warning: something like cloth simulation is to a game engine what a single cell is to a mouse. Game engines are huge, in other words, and again you won't be writing simulations, lots of (internal) integrations.

1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js

2 - https://github.com/d3/d3-force/tree/main/src

3 - https://processing.org/

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.

I have the opposite problem[0], one of the first programs I wrote as a child was bouncing ball sim. I didn't get the math behind it, I just fiddled with the code until it seemed right.

It's only a few lines of code, and it's still my "hello world" for any interactive programming system or gamedev library.

Make the ball respond to keyboard ... that's velocity! But it's too jerky, so we wanna smooth it out... that's acceleration! Make it fall, that's gravity! (Constant acceleration in one direction.) Ball keeps moving endlessly is weird, let's make it slow down a tiny bit each frame... hey look, that's friction!

The next year in school we learned the math for most of the same stuff (velocity, acceleration, gravity, friction) and it was pretty straightforward to me (even though I still suck at math) because I already had the "instantaneous" (frame by frame) model built up from making it in code, so I could sorta-kinda translate that to the continuous (formula-based) perspective.

I made a cloth thingy like this a few years ago after watching a video about it. The actual cloth sim code is like, 3 lines iirc.

It basically just jiggles the system a few times based on stuff being too close or too far away. So the idea is that the movement of one part transfers to all the others.

I'm a bit confused now since I saw some that have hard limits on the segment length (e.g. chain sims), whereas this one seems to be more stretchy (spring based?)

The neat thing about this stuff is that if you aren't going for physical accuracy (or efficiency), you can half-ass it by just guessing and fiddling with the code or the math. E.g. I still don't get how springs actually work, but my own terrible guess works well enough to be amusing!

[0] Whereas after repeated attempts over decades, web never really clicked for me. Well, it did when PHP was popular... I can still make stuff with PHP and vanilla JS, hahaha.

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.

If you aren't ready for it in 3d, do it in 2d.