Hello, World! Just keeping you guys up to date with what we are doing. I’d like to introduce someone who’s joining me in development of RTPS, Andrew Young. He’s a student at DSC interested in GPU computing and his current project is working on rendering techniques. Check us out:
[RTPS] Fluid Surface and Collisions in the works from Ian Johnson on Vimeo.
So this is kind of like a progress report with some pretty pictures, we still have a lot of work to do! Andrew is working on his blog where he will explain in more detail where he is at in his implementation of Screen Space Fluid Rendering and I will link to his post as soon as it’s up.
As for my progress, I’ve been slowed down by a couple of troubling bugs in the simulation as well as some idiosyncrasies of GPU programming. Things are a bit better now but I still have some hunting to do to find the root cause of the simulation bug, and there is some optimization and resource monitoring needed for OpenCL on older graphics cards.
At the same time I have been working on features like Triangle collision, which I consider half-way complete. The fluid particles collide with the triangles (obtained from the Blender object’s mesh, needs to be in triangle form, no quads) correctly, but the forces we use to influence the particles are not good enough. We have some ideas on how to improve this (involving placing “ghost” particles on the triangles) so hopefully we will have some pretty accurate collisions soon. Next on the list is improving the emitters so we can have a proper hose to spray fluid with different directions and initial velocities. I want to make either a custom object or modifier which will get rid of the awkward game properties settings I’m using now.
I have also been talking with another student in our group, Evan, about improving and expanding the OpenCL classes in RTPS for use in other libraries. This could potentially make life simpler for other developers, because we’ve already abstracted away a lot of the tedious details for stuff we use a lot (1D arrays, CL/GL context sharing) but we would need to properly engineer some other things (cl source code and kernel management, better context management and exposing more functionality).
I’m also quite excited about this proposal for an OpenCL based compositor. I’ve been learning a lot of OpenCL in the last months, but it will take a concerted effort of more developers to get projects like mine and the compositor ready for a consumer grade application like Blender.
Exciting times :)
Haha this is awesome, I didn’t know you can speak Mandarin Chinese so well! Bravo and keep up the good work!
Pingback: Fluids in BGE Update: Surface and Collisions in the works | BlenderNation
Guys, this is beautifull, but tell me why you don’t use bullet for the collisions? Bullet has also some sph fluids implementation, and it also is OpenCL, maybe you could just put your code into the bullet library and then use all the goodies of the physics system – you could have floating objects reacting to the fluid and opposite, constraints e.t.c.
@vilda if only it was so easy ;)
The SPH in Bullet does not have an OpenCL implementation, and we are developing our code so that it is a standalone and open source library. So it will be possible to integrate with Bullet. As our library matures we certainly plan to integrate better with Bullet, GameKit and the BGE
great work guys. keep it up. \fps looks pretty decent too!
This looks great, and I hope your work with Evan on using this as a C-library works out well. I can help with Python ctypes wrappers.