Hey this was also the first fluid sim paper I ever implemented! I haven't done any grid-based simulations (except maybe the classic "Real-Time Fluid Dynamics for Games" by Jos Stam), but I've been able to greatly improve compressibility by using "Position-Based Fluids" by Miles Macklin. Someday I'll dive into WebGPU and post a JS version on HN...
In skydiving, it isn't unheard of for someone to have their phone fall out of their pocket and survive impact without the screen shattering. That's from ~13000ft, but once the phone reaches terminal velocity, it's all the same impact force regardless of altitude.
I think dirt/grass is just a lot softer than the things we usually drop our phones over, like concrete or tile.
I recently went this route. I didn’t want to set up or use Unity so I wrote my own 2D fluid simulator based on some of the same papers using Metal compute shaders (though I’d love to try again using webgpu). Sebastian’s video is great and the implementation is good. But this was a great (and fun) opportunity to look for ways to improve on it.
For starters, the way he’s doing the spatial lookup has poor cache performance, each neighbor lookup is another scattered read. Instead of rearranging an array of indices when doing the sort, just rearrange the particle values themselves. That way you're doing sequential reads for each grid cell you look for neighbors in, instead of a series of scattered reads. The performance improvement I got was about 2x, which was pretty impressive for such a simple change.
The sorting algorithm used isn’t the fastest, counting sort had much better performance for me and was simpler for me to conceptualize. It involves doing a prefix sum though, which is easy to do sequentially on the CPU but more of a challenge if you want to try keeping it on the GPU. "Fast Fixed-Radius Nearest Neighbors: Interactive Million-Particle Fluids", by Hoetzlein et al [0].
Or, if you want to keep using bitonic sort, you can take advantage of threadgroup memory to act as a sort of workspace during bitonic merge steps that are working on small enough chunks of memory. The threadgroup memory is located on the GPU die, so it has better read/write performance.
I ended up converting his pure SPH implementation to use PBF ("Position Based Fluids", Macklin et al, [1]), which is still SPH-based but maintains constant density using a density constraint solver instead of a pressure force. It seems to squeeze more stability out of each “iteration” (for SPH that’s breaking up a single frame into multiple substeps, but with PBF you can also run more iterations of the constraint solver). It’s also a whole lot less “bouncy”. One note: I had to multiply the position updates by a stiffness factor (about 0.1 in my case) to get stability, the paper doesn’t talk about this so maybe I’m doing something wrong.
The PBF paper talks about doing vorticity confinement. It’s implemented exactly as stated in the paper but I struggled for a bit to realize I could still do this in 2D. You just have to recognize that while the first cross product produces the signed magnitude of a vector pointing out of the screen, the second cross product will produce a 2D vector in the same plane as the screen. So there’s no funny business in 2D like I had originally thought. Though, you can skip vorticity confinement, the changes aren't very significant.
There’s a better (maybe a bit more expensive) method of doing surface tension/avoiding particle clustering. It behaves a lot more like fluids in real life do and avoids the “tendril-y” behavior he mentions in the video. "Versatile surface tension and adhesion for SPH fluids" by Akinci et al [2].
One of the comments on Sebastian's video mentions that doing density kernel corrections using Shepard interpolation should improve the fluid surface. I searched and found this method in a bunch of papers, including "Consistent Shepard Interpolation for SPH-Based Fluid Animation" by Reinhardt et al, [3] (I never implemented the full solution that paper proposes, though). There's kernel corrections, and then there's kernel gradient corrections, which I never got working. With the kernel corrections alone, the surface of the fluid seems to "bunch up" less when it moves, and it was pretty simple to implement. Otherwise, the surface looks a bit like a slinky or crinkling paper with particles being pushed out from the surface boundary.
I found [0] and [1] on my own but I found [2] through a thesis, "Real-time Interactive Simulation of Diverse Particle-Based Fluids" by Niall Tessier-Lavigne [4]. I also use the 2nd order integration step formula from that paper. It has some other excellent ideas that are worth trying.
Many years ago I used a paper (that is in fact one referenced by Sebastian’s video) and some C sample code I found to write an SPH simulator in OpenCL. I had been wanting to write one again but this time get a real understanding of the underlying mathematics now that I have some more tools under my belt. I owe it to Sebastian that I finally started on my implementation and I understand SPH a lot more now.
Written english is often only a second language for Deaf and hard-of-hearing people. Sign languages have their own idioms, culture, and identity; ASL isn’t signed English.
I previously worked at a video relay service company (VRS in the US is a service paid for by the TRS fund through the FCC, and allows Deaf and hard-of-hearing people to make phone calls through video-chat with a ASL interpreter). In written English-based interactions with Deaf and hard-of-hearing colleagues, there is often a communication barrier as there often is with anyone speaking a second language.
In my personal experience working on tickets written by D/deaf colleagues, while sometimes we could communicate by whiteboard or text-based chat, it was indispensable to have the option to discuss the ticket with someone who could interpret present.
The passcode fallback isn't available for passwords, just for unlocking the device. In fact, IIRC I don't think you can set up iCloud Keychain without FaceID being enabled...
There's a conflicting forecast here[0], that says it's decaying. The graphic for the "decaying" forecast says it's a forecast for 10am EDT. The forecast linked in OP says it's for 2am EDT, which is before the publish date for that forecast. So something's weird with the publish date listed on the forecast, I'm not sure I would trust that date.
Seems like it's decaying, the decaying forecast is linked on their homepage and other space weather sites are forecasting it decaying as well.
One might be able to do this with peer to peer networking through WebRTC. You still need a way to send each phone an SDP offer/answer but maybe this could be done with QR codes.
At my employer we use Objective-C++ to interface with some shared C++ code. Swift can use C directly but it can be useful to wrap a C library in an Obj-C interface to be easier to use in Swift.
At my local drop zone one of our pilots posted this video as a reminder of why we let the pilot know when we have large groups leaving the plane. Large groups outside like this can starve the elevator of airflow, and the sudden change in center of gravity is also a factor.
This seems like a weakness of a king air as a jump plane. The pilot has to throttle down the left engine so jumpers aren’t thrown into the tail on exit by the prop wash. I’m happy with our single-engine super caravan with its wide door so not so many people have to be outside to do big groups like this.
The page seems to assume that semicolon's keyCode is 59 so the modifier key in the demo only works with Firefox according to this table on MDN[0]. The keyCode for semicolon varies not only by keyboard layout but also by browser. Mine is 186.
I was considering using lib-tex (the library implementing texlive 2019 for this shell) last week for an iOS app I’m working on that needs to generate basic LaTeX images. It’s really impressive, these programs running in A-Shell are modified by renaming their `main()` function and making sure global/static variables are cleaned up so they can run as a separate thread in-process instead of spawning a separate process. I decided to use the more limited KaTeX instead because it sounds like a maintenance nightmare, making sure nothing leaks and updating everything every time a new version comes out...
I wonder if that process can be automated to a point where you could “lib-ize” any C/C++ project (sed replacing malloc/free with something that cleans up when the process “exits”, replacing exit/fork/etc, replacing static). I think that would really open up the number of interpreters available on iOS.
I don't think this is true... Apps below iOS 13 won't be able to use the new system-defined UIColors, yes, and users below iOS 13 can't change to the dark-mode using a switch in the Control Center, yes.
But you've been able to change the "user interface style" for view controllers since iOS 12 [0]. And you've been able to add UIColors to asset catalogs that change depending on that setting since iOS 12 as well.
I'll be honest, I haven't tried this myself. But either this works or Apple's documentation is wrong.
Phantom types aren't part of the language because they don't need to be. They're just empty types used as type parameters for structs, where the type parameter isn't actually used as a variable in the struct. It is more of a design pattern than a language feature.
I'm loving all the history of the atomic bomb and related articles, but I'm curious. Is this just a trend on HN right now or is something I'm not aware of going on?