Metaballs for VRay

[jacksc02]

what are the rendertimes like?

[MasterBercon]

Like dimo said its very fast for opaque stuff, but thats not very useful. For transparent it gets pretty slow.

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

This took 5 minutes to render. Its the worst case scenario where you have 100 000 particles forming thick volume. When tracing rays inside you have to take very small steps all the way to the other side of the volume. There ain't any way to make it go faster. This scene would probably render in 30 sec if it was using meshed surface instead.

The benifit of using implicit surface is that you can zoom in as close as you want and it keeps smooth. Also it doesn't require much ram and its slow only when you are rendering it, if it takes just a small portion of the image it doesn't give any performance hit. If you were to mesh it, you'd have to do it no matter how small the object is. Implicit surface also allows true motion blur which isn't practical on meshed surface.

[MasterBercon]

Hey dimo or vlado.

How should I make the MovingPrimitive version?

Now I have the same structure as in VRaySphere example where I have 3 classes. The max dummy class, VRay instance class and primitive class.

VRay instance class already inherits the StaticPrimitive, should I change it to DynamicPrimitive or just inherit both StaticPrimitive and MovingPrimitive and do the same for the primitive class? Inheriting both doesn't actually seem to work since it doesn't know what to cast them then...

Shoud I have seperate primitive classes for static and moving geometry or can I handle them in the same class (which is what I'd prefer)?

[vlado]

There should be separate classes for the static and moving cases, purely for performance and RAM reasons; you can take a look at the VRayFur example which implements this.

Best regards,
Vlado

[Sascha Selent]

You are crazy

Great stuff - can´t wait to play around...

[duke2]

I don't know if this is related or not:

http://levelofdetail.wordpress.com/2...-space-meshes/

[dimo]

Hi Jerry,

what I did for getting motionblur without overcomplicating the code is that I expanded my boxes of the bvh with the start and stop positions.
This way I could reuse most of the code. Since normally particles only travel a short amount in one frame this is good enough I think.

Best regards,
Dieter

[MasterBercon]

From what I understand internally VRay works in 1.0 per frame time, frame 0=0.0, frame 1=1.0, frame 2=2.0 etc. and max works in 0=0, 1=160, 2=320.

Anyway my objects shows up correctly in frame 0 but it disapears in all the other frames (>0). Even if its stationary and MovingBox.b[1] is just pmin/pmax=(0,0,0). I guess it has something to do with time values t[0] and t[1] not matching but neither setting them in VRay time (1.0 and 2.0 or 160 and 320 in frame 1) works. Is there some other times settings that I should update?

Its not calling intersect() even once so the problem isn't there. It just doesn't find the object at all.

[vlado]

I guess it has something to do with time values t[0] and t[1] not matching but neither setting them in VRay time (1.0 and 2.0 or 160 and 320 in frame 1) works. Is there some other times settings that I should update?

These values are always relative to the current motion blur interval, so for 1-segmented motion blur they should always be 0.0 and 1.0 respectively.

Best regards,
Vlado

[MasterBercon]

Thanks vlado! Great response time. I guess that ends my questions on this issue.

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

Now all the features are working perfectly. All it needs is some heavy optimizations. For example the motion blurred version is pretty slow and there are at least few things I know how to make it faster so there is no point doing any speed tests atm.

[MasterBercon]

Now they are standing on pretty equal grounds in terms of optimizations.

The moving version uses similar dynamic bouding boxes like VRay (MovingBox) so they change slightly depending on the time you shoot the ray at them. I think its less expensive than having bigger static bounding boxes and iterating through more points.

It also caches the point locations per ray. So each blobs position is calculated only once per ray or actually twice if getNormal() is called. I should probably compute it always to avoid this and just live with the overhead in shadow rays.

With these optimizations it comes pretty close in terms of performace to the static version. Its slightly better than what I expected.

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

Now there are still more minor optimizations (normal mentioned above etc.) I can make but they don't radically alter the performance. Perhaps in this example they would take off a second or two but no more.

Dimo, you said you implemented the metaball field function from the "Animating Sand as a Fluid" by Zhu and Bridson. Could you shed some light on this because I'm not sure I understand it.

Is the general idea this?
for (b : blobs from here) kernel(b) / [for (c : blobs from b) kernel(c)]
Sound pretty damn heavy to me... Instead of N computations you'll do N*N computations.

[dimo]

Hey,

that looks good. I wonder how much speed you gained with the moving boxes compared to my static bigger boxes.
We have to do a speed comparison.

The Zhu Bridson stuff is slightly more expensive, yes. But it's not N*N.
The Basic Idea is that instead of adding up the distance fields of the near metaballs you average the position of the metaballs and take the distance field of that position. The influence radius is the same (and therefore also the number of computations).

Hope this makes sense.

Best regards,
Dieter

[dimo]

From my experiments the Zhu Bridson stuff only looks good if the particles come from a fluid solver. the fluid solver will make sure they are equally spaced. This is essential for this algorithm.

[LarsSonparsson]

Looks really good! So when can we test it?

We are doing liquid simulations a lot and I would like to see
how this goes with realflow particles. Now big simulations and mesh
exports from realflow are sometimes quite hard way to go.

Excellent work MasterBercon!

-LarsSon

[MasterBercon]

It will be quite a while before its ready for testing. It lacks UI and internal interface to anything else than pflow. Even the pflow connection sucks atm. I'd say 1.5 months before its ready.

Dimo, so if I understand correctly (seems i just dont get it >.<) it goes something like this:

totalWeight = 0
totalPos = 0,0,0
for (int i=0;i<count;i++) totalWeight += kernel((pos - blobPos[i]).lengthSqr() / radius2)
for (int i=0;i<count;i++) totalPos += blobPos[i] * kernel((pos - blobPos[i]).lengthSqr() / radius2) / totalWeight
fieldStrength = 1 - (totalPos / count).lengthSqr() / radius2

So first caclulate total field strengh, then calculate average position for all particles, where their positions are weighted by their field contribution divided by the whole field strength.

Then just get the (squared)distance to this average position and use it as field strength?

Best regards,
Jerry