Theoretical Question : Blobmesh, PWrapper, ...?

[Bobo]

Please don’t read too much into this as it is still purely theoretical.

We would like to get some feedback from all of you regarding the currently available metaball solutions for 3ds Max.
We all know that Blobmesh is slow.
We have all heard the stories that PWrapper is fast(er).

Blobmesh is for free, but it is unusable in production.
PWrapper is nearly 295.00€ or about US$373 as a stand-alone plugin.

Let’s say you were given an alternative solution that does the same and a lot more, but MUCH faster and scales better with increased particle and polygon counts.

*Would you be interested in it?
*How many particles / how many polygons would you expect it to handle?
*How much would you pay for such an animal?
*Would you consider buying it as a separate plugin or would you prefer it being part of another product, causing a price increase of that product?

Thank you very much for your input!

[Chad]

We’ve indicated an interest in having the meshing system from Flood:Spray available without the simulation part, yes. Though we would likely also want Flood:Spray to be available too.

Pricing wise, you could sell it separately, but require a license of a compatible product, so it would be more like a added cost module for Krakatoa than a standalone. Not sure how your FlexLM pricing is done. Just as an additional option to consider.

Also, you could have a “lite” version that comes free with Krakatoa. It grabs a Krakatoa license, and it is limited to ONLY meshing PRT Loaders, perhaps implemented ONLY as a modifier? Could even limit the number of particles supported or the overall voxel count?

As for the suitability, I can think of some use cases… Obviously if you want to do waves crashing against a lighthouse or other madness, you’d need a lot of particles and a fine grid. But if you are just doing a viewport proxy for Krakatoa PRT Loaders so you can see lighting direction and intersection with other meshes, then you can get away with smaller particle numbers and courser grids. If you are doing meshed volume proxies to accelerate particle animation, like culling one particle system based on the density of another, then it’s probably somewhere in between.

But… If you are dumping the points off to a voxel array anyway, why would the point count matter? Don’t you just stream in and accumulate the density per voxel? It’s not some weird levelset thing is it? Just the voxel array size should matter, unless it’s a levelset thing, and then the actual distribution would matter, but beyond that I couldn’t comment. And couldn’t you initialize multiple grids at multiple resolutions ala ClayStudioPro? Makes the surfacing a bit trickier, but saves memory like none other, which is why you have particles in the first place, no? Ok, sure particles have other uses, but I don’t have to explain all that to anyone at Frantic.

Dunno what features are available at this time, but you could accumulate a lot more than just density… Color would be an obvious one, but why not normal or velocity or happiness? We’ve got nearly 100 vertex channels to fill, right? Just allow us to map particle data channel to vertex data channel… Ooolala! Further, could the voxel array not also be available as a texture map for assignment of materials back to either particles or the mesh? And if you had the particle-to-voxel conversion as a Pflow operator… Mmmmm… We’d pay double for sure!

Ben has a surfacing tool that he’s built (and extending) for our needs. It’s actually really interesting to try out different meshing techniques and optimization ideas. It works on voxels, not particles, however. It’s what I’ve been using for my testing of the KSW(WSM). I load in the dataset, extract the surface (snapshot of course) and deform.

[Bobo]

@Chad

We’ve indicated an interest in having the meshing system from Flood:Spray available without the simulation part, yes. Though we would likely also want Flood:Spray to be available too.

I know, the question was for the other beta testers, but…

Pricing wise, you could sell it separately, but require a license of a compatible product, so it would be more like a added cost module for Krakatoa than a standalone. Not sure how your FlexLM pricing is done. Just as an additional option to consider.

Yes, this is an option we have been tossing around.

Also, you could have a “lite” version that comes free with Krakatoa. It grabs a Krakatoa license, and it is limited to ONLY meshing PRT Loaders, perhaps implemented ONLY as a modifier? Could even limit the number of particles supported or the overall voxel count?

Nope, we don’t do light stuff. Anheuser-Busch does
All or nothing, although it would be modified from what we are using internally since right now we do only PRTs but want to support anything.

But… If you are dumping the points off to a voxel array anyway, why would the point count matter?

I never implied the particle count matters I just want to hear what other users would throw at it, especially if they have experience with the existing solutions. For example, if you create a default PFlow with inverted Speed of 300 and 30 degrees Divergence, emit N particles over 30 frames and mesh with default settings in PWrapper (and comparable settings in BlobMesh), you would get these numbers by playing back the 30 frames in the viewport:

5K PW:28 sec. (1.00x) BM: 82 sec. (1.00x)
10K PW:92 sec. (3.28x) BM: 169 sec. (2.06x)
20K PW:349 sec. (3.79x) BM: 333 sec. (1.97x)
40K PW:1332 sec. (3.81x) BM: 665 sec. (1.99x)
80K PW:5789 sec. (4.34x) BM: 1432 sec. (2.15x)

First column is number of particles on frame 30, second is PWrapper, then the slow down in brackets, then the BlobMesh and its slowdown caused by doubling the particle count. Funnily enough, BlobMesh scales better in this case…

How do we compare? That’s what I want to hear speculations of

Dunno what features are available at this time, but you could accumulate a lot more than just density… Color would be an obvious one, but why not normal or velocity or happiness? We’ve got nearly 100 vertex channels to fill, right? Just allow us to map particle data channel to vertex data channel… Ooolala!

Ooolala indeed. We do all of this. There is also explicit support for particle size or random variation using the ID channel.
We do NOT support the Happiness channel yet, but given the rest of the features, it might be obsolete

Once again, we have NOT decided to release it. We are considering our options.

[Chad]

@Bobo

@Chad

We’ve indicated an interest in having the meshing system from Flood:Spray available without the simulation part, yes. Though we would likely also want Flood:Spray to be available too.

I know, the question was for the other beta testers, but…

Right, I just didn’t know if it was the same thing, or something completely different. When I hear “metaballs” I think modeling tool, not surfacing tool.

Nope, we don’t do light stuff. Anheuser-Busch does
All or nothing, although it would be modified from what we are using internally since right now we do only PRTs but want to support anything.

But you’ve got a 2-server version of Deadline, right? This would be similar, a sort of taste of what’s possible.

We do NOT support the Happiness channel yet, but given the rest of the features, it might be obsolete

But if you read in channels from the PRT file itself, you can do whatever input channels are available. Regardless, I can see a lot of possibilities from the purely TD side. You can collect all sorts of data from your particles into an array and birth out new particles or test them or whatever. Could be a really nice way to handle really nasty scenarios. And that’s what PRT’s and Krakatoa is really good at anyway. It’s not just rendering, but making TD’s jobs more pleasant.

You could surface FumeFX, too.

[Bobo]

@Chad

You could surface FumeFX, too.

I am pretty sure we are not allowed to touch their data.

[JohnnyRandom]

Caching the mesh.

If not some form of caching, some type of memory management.

Multi-threading if possible, another huge downfall of both pwrapper and blobmess.

Friction types air/fluid, maybe viscosity in relation to droplet size. Most of this is controlled by the particle system but obviously the larger the droplet size the more these attributes would come into play.

If it had a form of cache it seems it would handle whatever you could throw at it. At the least nice splashes, splats, smears, small to mid size volumes. Larger volumes would be great

In your test scenario is that “emit N particles over 30 seconds” correct? or is supposed to be frames? I gather its frames, my times are more inline then.

Well since I haven’t gotten a specific pay-job to use pwrapper yet, I can only say I have been tempted to buy it more than a half dozen times, if the dollar was still even money w/ the euro I would have purchased it 5 times ago (still playing with the demo). Then again, due to the limited nature of pwrapper I consider it more in the range of $195-245. It does one thing wrap particles and does an ok job at that, it could use a few feature improvements as I listed above. So to answer your 3rd question, I would pay a similar amount for a similar feature base, obviously the more feature rich it is would certainly bring up it’s value and it would be worth paying more for.

I’d prefer it to be a separate plug-in with tight integration to the other line products, myself. If/when you guys release your other fluids applications I would expect it to compliment it (I think I am preaching to the choir here). If it is bundled with say Krakatoa and someone just wants a particle wrapper then you may lose a purchase, better business sense as individual components (even if you don’t plan/expect to get rich off of it) you’ll fair better to a wider market. Of course you can then offer bundles w/ applicable discounts as well.

Oh you can surface FumeFX with a PRT loader and prwapper but I see your point , and I am sure you already knew that.

[Bobo]

@JohnnyRandom

Caching the mesh.

We have an in-house caching system that does that with anything that outputs a triMesh. We are not talking about that here. Keep in mind that caching requires the same time needed to play back or render at that resolution, so in many cases it would make things faster after a long initial wait. And then you realize you want to change your settings and you have to start again…

Multi-threading if possible, another huge downfall of both pwrapper and blobmess.

Deal!

Friction types air/fluid, maybe viscosity in relation to droplet size. Most of this is controlled by the particle system but obviously the larger the droplet size the more these attributes would come into play.

This is surely not part of the surfacing system, it should happen at simulation time. We just read a point cloud and turn it into a mesh in various ways.

If it had a form of cache it seems it would handle whatever you could throw at it. At the least nice splashes, splats, smears, small to mid size volumes. Larger volumes would be great

We discovered that large volumes are the downfall of pWrapper. The larger the volumes and the denser the particles, the worse it gets. And it scales really badly if the particle count goes up but the particles are not spaced evenly. It is relatively usable in the up to 10K particles range. But we want to deal with Krakatoa numbers here

In your test scenario is that “emit N particles over 30 seconds” correct? or is supposed to be frames? I gather its frames, my times are more inline then.

Nope, 30 FRAMES. We did that because with something like 80K particles, both PWrapper and Blobmesh would become ridiculously slow and we needed some finite time to measure the result without waiting overnight.

Oh you can surface FumeFX with a PRT loader and prwapper but I see your point

Of course, but you have to generate particles first. I was talking about accessing their voxel data.

[JohnnyRandom]

When I say ‘cache the mesh’ I guess more appropriately stated as the option to bake it. So you have realtime intactivity but you have the option to bake it before you render, saving overhead during render time. That’s all Pwrapper certainly runs into problems in this area, I have have a half decent looking wrap, go to render and it out-memory-errors out at half way through the render.

So are you saying you just want to skin a point cloud? I guess maybe I am a little confused

Because both blob and pwrap have tension settings (as you know), hence the idea of fluid friction and viscosity, which I guess is similar to pwraps melt force but it seems limited. It is akin to bubble/air interactivity with current fluid simulators (which is nearly non-existent) to me, it looks good but just needs that little extra to top it off More surface tension and friction control would be cool, especially with lower densities.

Agreed, Particle density is horrible with both, pwrapper just starts to look good when you get a lot of particles, your drop size below 0.8, and detail 16.0+ but that’s also when it seems to start hitting the ceiling.

I was talking about accessing their voxel data.

Gotcha! hmmmm…I guess you never know until you ask

[Bobo]

@JohnnyRandom

When I say ‘cache the mesh’ I guess more appropriately stated as the option to bake it. So you have realtime intactivity but you have the option to bake it before you render, saving overhead during render time. That’s all Pwrapper certainly runs into problems in this area, I have have a half decent looking wrap, go to render and it out-memory-errors out at half way through the render.

As I said, we do have such a tool, but it is not going to ever be made commercial. With the speed we provide, meshing on the network is not a big deal (although in many cases it would be better for the network to load a mesh cache than all particles to be meshed)

So are you saying you just want to skin a point cloud? I guess maybe I am a little confused
Because both blob and pwrap have tension settings (as you know), hence the idea of fluid friction and viscosity, which I guess is similar to pwraps melt force but it seems limited. It is akin to bubble/air interactivity with current fluid simulators (which is nearly non-existent) to me, it looks good but just needs that little extra to top it off More surface tension and friction control would be cool, especially with lower densities.

The Tension parameter is part of the metaballs algorithm. Our tool provides metaballs as one of the options, but we barely use it, since we provide a better algorithm. Also, PWrapper does an internal Relax on the final mesh to make it look more fluidy, you can drop a Relax on Blobmesh or our tool to get the same look, practically in realtime. So we do the same (and more) as the existing ones. Just much much faster.

Gotcha! hmmmm…I guess you never know until you ask

Who says we haven’t…

[JohnnyRandom]

Sorry for the late reply

Caching understood

Relax understood That seems very enticing! nearly realtime,I would have to coin the term “That’s Incredible!”

Voxel data understood