I decided to try and write rendertime metaballs for VRay. Basicly what you get with Blobmesh but infinitely smooth and nearly zero memory consumption, rendering million particles shouldn’t be a problem.
I’ll report progress here if anything comes out of it. Here is the first “proof of concept” screenshot rendered with VRay.
Dieter’s implementation is actually not only a test anymore. We’re actively using it in production every now and then (to render quite some water stuff for a recent job for example). The latest public build is still available for free and not timebombed anymore if i recall right. Does moBlur and works with PFlow systems.
the metaballs are not on the site. I only have the VRayISO there. The Blob stuff was partly developed at mackevision and because of that I am not allowed to either release it or make it open source. Sorry for that.
I’ll probably start with static version and if it comes out fine I’ll make one which supports motion blur. Atm I don’t really even know where to start with the dynamic version. Could you point me in the right direction dimo?
I’ll try to make mine take in any point clouds, this includes all particle systems and meshes (verties). And perhaps support for maxscript so you could write import for practically anything.
To make it dynamic I stored both the position at the beginning of the interval and at the end of the intervall for each particle. When VRay gives you the ray to intersect, it will also give you the time value which you can use to interpolate the position for each particle. Codewise it’s no big difference to the static version, of course slower in rendering.
Most important thing is to use an acceleration structure for the point cloud and to have some kind of early termination. I used a BvH, which worked fine.
My approach calculated the surface new for each ray, which leads to perfect smooth surfaces.
This was very fast for opaque materials, because of the early termination. Another advantage was that it immediately starts rendering without the delay of setting up a mesh, and if your metaballs are not seen by camera rays they won’t waste time with mesh tesselation.
The problem I had was that if you have a refractive material like water and a lot of particles in your ray, you have to do a lot of calculations, and it get’s very slow.
At the end, for water it may be more efficient to tesselate to a rendertime mesh.
So you built BvH with bounding boxes and to check which points where near enough?
Did you use it also to trace intersections to find if any points were along the ray and then started marching iterativly from the first bounding box intersection forward? Or does VRay already do this for me since my blobmesh supports splitBounding box methods and is splitable?
First build up BVH with Boxes like the black boxes in the image. I can use them to optimize getting near points for field calculation and I can use them to avoid interating any rays that don’t intersect with leafs of BVH. Is this a good way to do it?
I was thinking of first creating bounding box for the entire point cloud, then splitting it in half again and again until I reach required depth or small enough leaf size.
The second optimization that comes to mind is that I could intersect the Outer Bound spheres of the all points that I get when intersecting BVH. This would futher narrow down my need to iterate the potential field.
Third optimization would be for transparent metaballs. When ray starts inside the field instead of starting to move normal iteration steps I could directly jump to surface of the nearest points Inner Bound sphere.
Now its got simple BVH to discard rays that don’t intersect anything and to find near points.
Very crude render with 100 000 particles, 0.5 step size and 2.0 blob size renders in 25s on 6600Q @ 3.2GHz. Its suprisingly fast compared to how poor my optimizations are at this point.
If you zoom close you’ll notice artifacts (“banding”) caused by the large spep size, since it doesn’t even refine the exact hit location, just leaves it there.
Stretching is possible but I think it would increase the rendertimes quite a bit. I’ll look into it once I’ve gotten the static system work and move on to dynamic (motion blur) version.
“Did you use it also to trace intersections to find if any points were along the ray and then started marching iterativly from the first bounding box intersection forward?”
Yes, that’s exactly what I did. I first check the intersected leafs and order the intersected ones into an array in the order of their intersection. The only tricky part is to keep track of which boxes you are intersecting at each step. But this way it’s realy fast for opaque materials.
I tried both normal metaball algorithm and the zhu/bridson approach:
Looking good. Do you think you’ll add a relax parameter ?
