Metaballs for VRay

[RErender]

Looking good, looking forward to this one, always looking for a good way to render water.

in that thought, stretch and squish would be nice or even speed stretch and flatten ala realflow meshing.

[MasterBercon]

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.

There is not relax parameter but adjust threshold value does give similar effects: http://www.niksula.cs.hut.fi/~jylila...taballs_06.jpg

[dimo]

Hi Bercon,

"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:
http://www.cs.ubc.ca/~rbridson/docs/...-sandfluid.pdf


Best regards,

Dieter

[MasterBercon]

Thanks Dieter, I have to check out that zhu/bridson approach sounds intresting.

I've now succesfully made the BVH optimizations for opaque blobs. Its amazingly fast. Still some major stuff missing but anyway.

10 000 000 particles. Renders in ~140 seconds with Q6600 @ 3.2Ghz. Eats roughly 150MB memory or something along those lines. The major slowdown is caused by pflow. If I'd use pointcloud from mesh it would probably be a lot faster (30 seconds or something around there). I'll have to add mesh verties as blobs support for that.
http://www.niksula.cs.hut.fi/~jylila...taballs_07.jpg
http://www.niksula.cs.hut.fi/~jylila...taballs_08.jpg

Here is a test just to check everything is fine with the surface, supports GI, reflections, shadows etc.
http://www.niksula.cs.hut.fi/~jylila...taballs_09.jpg

[gagui]

Wow!! Looks fantastic.

[mik]

really impressive work Masterbercon !!
your tools are always very useful
And the 3d community really need an alternative to the realflow mesh or blob mesh

thanks a lot

ps: sorry for my english

[MasterBercon]

Transparency and shadows are giving me major headache at the moment.

Reflections and refractions work just fine if nothing is inside the blob but as you can see in the picture, it doesn't like other objects.

Second problem is shadows, they just don't really work. There is some shadowing but its "missing" a lot of the blobs and is just buggy.

http://www.niksula.cs.hut.fi/~jylila...taballs_13.jpg

The following questions are mainly for vlado and dimo and other who understand what happens under the hood.

I don't really understand how the shadow rays differ from normal rays? If normal rays work why don't shadows?

Should I use the SkipTag thingy somehow? At the moment I just set it but don't really use it at all.

Now I'm doing following: Searching first intersection from RSRay.p to RSRay.dir direction.

I think the problems might be caused by not taking cmint and cmaxt account, I just return false if the FIRST interscetion found doesn't match that range. Do those tell the range along the range where I should be searching the intersection?

I could give the entire source code here but its kind a mess so if you can see any obvious errors in what I'm doing it'd be helpfull.

[dimo]

Hi Jerry,

I will give it a shot. I guess Vlado has a deja vue, because those are the same questions I had back then.

Transparency and shadows are giving me major headache at the moment.

Reflections and refractions work just fine if nothing is inside the blob but as you can see in the picture, it doesn't like other objects.

make sure that you check: if t is your intersection:
if (t>ray.is.t) return false;
if (t<=ray.cmint) return false;
if (t>=ray.cmaxt) return false;

Second problem is shadows, they just don't really work. There is some shadowing but its "missing" a lot of the blobs and is just buggy.

The following questions are mainly for vlado and dimo and other who understand what happens under the hood.

I don't really understand how the shadow rays differ from normal rays? If normal rays work why don't shadows?

You have to adjust your step size to the ray direction length. Shadow rays often have a not normalized ray direction length.

Should I use the SkipTag thingy somehow? At the moment I just set it but don't really use it at all.

// If the origin is near the surface, make sure we get sufficiently away from it to avoid "surface acne"
if (this==ray.skipTag) {
do {
tLeft+=stepsize;
dLeft = computeField....

}while (tLeft<t1 && fabsf(dLeft)<1e-3f);

Now I'm doing following: Searching first intersection from RSRay.p to RSRay.dir direction.

I think the problems might be caused by not taking cmint and cmaxt account, I just return false if the FIRST interscetion found doesn't match that range. Do those tell the range along the range where I should be searching the intersection?

What I did is only look for an intersection between
float t0=ray.cmint;
float t1=ray.cmaxt;
and if
if (t0>ray.is.t) return false;

I could give the entire source code here but its kind a mess so if you can see any obvious errors in what I'm doing it'd be helpfull.

Let me know when you have something to test, I am always interested in speed comparisons
Dieter

[MasterBercon]

Thanks Dieter!

Unnormalized direction vectors?!? What were they thinking....

Okey now I've nailed nearly all problems. There is still problem with Affect Shadows on.

http://www.niksula.cs.hut.fi/~jylila...taballs_14.jpg

It seems the rays never leave the object (they miss one intersection?) so the fog color affects them all the way until they reach the light and get tinted too much.

EDIT:

Okey it seems I was too early to celebrate. How are ray.cmint and ray.cmaxt actually affected by this non-unit direction vector? Does ray.p + ray.dir * ray.cmint always give me the starting location in world space? Should I scale ray.cmint with ray.dir.length()? How should the intersection distance (ray.is.t) be set? Along the not-unit direction vector or along normalized direction vector?

[MasterBercon]

Okey now its finally fully working and I got all the problems fixed.

http://www.niksula.cs.hut.fi/~jylila...taballs_16.jpg

Time to implement some more field algorithms and checkout how motion blur would work out. Then perhaps some more optimizations.

[Shimakaze]

Waw! Awesome!!!!
Can't wait to try it out

[simmsimaging]

Wow Looks amazing so far.
b

[vlado]

Okey it seems I was too early to celebrate. How are ray.cmint and ray.cmaxt actually affected by this non-unit direction vector? Does ray.p + ray.dir * ray.cmint always give me the starting location in world space? Should I scale ray.cmint with ray.dir.length()? How should the intersection distance (ray.is.t) be set? Along the not-unit direction vector or along normalized direction vector?

Seems like you found the answer already, but still, during intersection you only work with the (potentially unnormalized) ray that is passed to your primitive.

Best regards,
Vlado

[MasterBercon]

Yeah so you always work with points along the unnormalized direction ray. It took me awhile to understand that when I seek bounding volume intersections along these rays it also returns the intersections in along this ray, I was scaling them with its length which is wrong.

I'm using the IRay and Box classes with the bounding volume which is why I wasn't quite sure what it was even doing =P

[skogskalle]

wow. I understad absolutely nothing of this. But i love the results

keep up the good work!
/k