Closed Fourmisain closed 3 years ago
Just built this:
The points are randomly chosen and interpolated between using a Smoothstep function.
The range goes from -1 to 1 and could be used as the leaf acceleration in one axis. If you imagine the X-axis of the graph being time, at each point in time we only need two points to interpolate between, making this very efficient.
Hm... there's a few things that don't make this work well:
One idea might be to have states like "calm", "windy" and "stormy" which will last for a much longer time.
All in all: modeling wind is hard.
Wind now has states and instead of using smooth noise for both axes, it uses noise for the wind strength and direction.
The strength (distribution) is decided by the state, while the direction follows a "trend" that very slowly changes and also has some fast changing variation.
The "calm" and "windy" states look pretty good to me, not so sure about the "stormy" one, because it's not much different from windy; it also needs to be locked behind a weather condition.
It's annoying that particles get permanently stopped on the ground while they barely slow down when floating on water.
There's probably no way around implementing our own move()
method.
Currently there's a debug key H to change the state.
Currently, wind is modeled as a global acceleration and since I removed the drag force, I believe that leaves now have an unbounded velocity. This is not a huge issue since leaves always fall down so they are mostly limited in the speed they can gain until they reach the ground. They do like skating on water with ever increasing speeds, though.
I'm still thinking about how to approach this, maybe wind should just be a kind of target velocity that each leaf is approaching, e.g. like
velocity += 0.05 * (targetVelocity - velocity);
So leaves initially speed up fast but the closer they get to the target velocity / wind speed, the less the velocity changes; so it closely (but not perfectly) follows the wind speed.
That should be close to a full acceleration/drag simulation while being cheap to compute.
Also, it is still not clear why Wind.tick()
can be called before Wind.init()
and cause a crash - it's easy to fix, but better to find out why.
Alright, Wind.tick()
was called before Wind.init()
because the latter was simply not called when joining a server.
Fixed in https://github.com/RandomMcSomethin/fallingleaves/commit/d5cc5ac3074ef513cab6af56d886c9f1424f2d5d and rebased the wind branch.
Wind is now a target velocity that is approached by the particles, I also removed the collision workaround (and fade-in) again for now.
Wind.init()
should be in a much more reliable place now, though I still left the initial call to it.
Particles also slow down in water.
I found that particles do not move with moving water, though that is a really small detail that might not even be worth it.
I feel wind should probably be disabled in the nether and possibly the end, it doesn't feel right in those dimensions. The nether has a ceiling and can be pretty closed off while the end is like a "space" dimension - though it does have breathable air.
Finally merged the wind branch https://github.com/RandomMcSomethin/fallingleaves/commit/20ce0594f48cca33c5a231c00f7962a3a184597c!
Old idea, just thought I'd put it here so we don't forget about it: