4 ms·
I think I was pushing the limits of what the service could handle with my fluid simulations. They're pretty choppy on first playback, but run smoothly the secon
by slavik81 8y ago
I think I was pushing the limits of what the service could handle with my fluid simulations. They're pretty choppy on first playback, but run smoothly the second time.
Block - https://asciinema.org/a/125371 https://asciinema.org/a/125371
Waterfall - https://asciinema.org/a/125380 https://asciinema.org/a/125380
- warent 8y agoThose are worth an HN thread of their own imo. Maybe a blog post or github page explaining how you did this
- slavik81 8y agoI built it to be a reference implementation for "Fluid Simulation for Computer Graphics" (1st Ed.) by Robert Bridson. The book is a cleaned up version of his free course notes. If I had the time, I'd clean up the code a little because the book already has a great explanation of how it works. https://github.com/cgmb/euler https://github.com/cgmb/euler
- czardoz 8y agoWow!
- bewuethr 8y agoThese remind me of the ASCII fluid submission [0] at IOCCC 2012 [1] by Yusuke Endoh. The source [2] itself can be used as an input to the program (see video [3]), and he also made a colour version [4]. [0]: https://www.ioccc.org/2012/endoh1/hint.html https://www.ioccc.org/2012/endoh1/hint.html [1]: https://www.ioccc.org/2012 https://www.ioccc.org/2012 [2]: https://www.ioccc.org/2012/endoh1/endoh1.c https://www.ioccc.org/2012/endoh1/endoh1.c [3]: https://youtu.be/QMYfkOtYYlg https://youtu.be/QMYfkOtYYlg [4]: https://www.ioccc.org/2012/endoh1/endoh1_color.c https://www.ioccc.org/2012/endoh1/endoh1_color.c
- slavik81 8y agoThat was one of the inspirations for my work. His simulation is Lagrangian (particle-based) while mine is Eularian (grid-based).