box 2 and fluid simulation

[savat]

no interest to this argument?...ok

[3DMadness]

I'm really interested on this, but for now I don't have box#2, can you upload a video in youtube?

[jigu]

hmm sounds cool. Can you post video?... I can also think of another plugin if it can be used with box#2, sure it can make cool fluids. But I am not sure if I can speak of about that plugin yet. Maybe Bobo can speak more. ;)

[JohnnyRandom]

no interest to this argument?...ok

I think more interest will generate with the release of the highly anticipated (at least by me) release of PhysX 3.0 SDK which is supposed to have 64-bit support.

Right now the current particle limit to PhysX is around 65K particles (or Actors), which in comparison to any serious fluid simulator is but a drop in the bucket so to speak. Rumor has it with the implementation of 64-bit that cap will be raised (although I doubt removed) to hopefully more usable particle counts in relation to fluids.

AFAIK Box#2 has not yet implemented an SPH solver. PhysX does have one so maybe in a future release :)

I have done a few Box#2 fluid like tests, results are certainly fine for a small scale quick shot IMO. The problem lies within the particle skinning. The particle wrapper has no way of determining collisions so you get mesh penetration on your collision objects.

[jigu]

As this was already posted by Bobo in Krakatoa thread. I think I can post it here too.

Here is the link (http://software.primefocusworld.com/software/support/krakatoa/krakatoa_skinwrap_particle_and_mesh_deformations.php) for Krakatoa KSW feature. But that's not what I am talking. Look at the bottom of the page for PRT mesher.

That's something new cool thing. (Another option after blobmesh and pwrapper) :D

[SoLiTuDe]

^Yeah, the prt mesher is great... too bad it's not commercially available. :D


On topic, and I've also said this before -- the Ageia fluids suck.... great for games, sure, but not for real fluids work. ... but at least it's better than nothing I guess! Also, using spheres as fluids also only goes so far, but you can fake quite a bit with it... maybe for stuff pouring in a cup or something.

[jigu]

What about making such stuff like flooding street using box#2 tools? (Imaging the shot flood shot like from film "Poseidon" - tunnel flooding shot..)

Box#2 uses agia physx fluid stuff? Is it implemented in it?

[savat]

Right now the current particle limit to PhysX is around 65K particles (or Actors), which in comparison to any serious fluid simulator is but a drop in the bucket so to speak.


sure, muthc more then 1 or 2 limitations but for small watery scenes its abilities are a new tool for a max user (better then glu3d in dynamic interactions) and cooperanting, again, also whit glu3d-PFlow operators we have other potentials...an evolving stuff vs a money expensive stuff like Real Flow.


I have done a few Box#2 fluid like tests, results are certainly fine for a small scale quick shot IMO. The problem lies within the particle skinning. The particle wrapper has no way of determining collisions so you get mesh penetration on your collision objects.

in my tests I use for radius "collision shape size" and blob radius the same size and don't have mesh penetration.

Comparing a filling glass test using box#2 (A) and glu3d (B) I've noticed that the particle flow in A is too turbolent that in B cause upper particles crush bottom particles...if I resolve that then I'll post somewhat

[SoLiTuDe]

What about making such stuff like flooding street using box#2 tools? (Imaging the shot flood shot like from film "Poseidon" - tunnel flooding shot..)

Box#2 uses agia physx fluid stuff? Is it implemented in it?

Box2 does not have any fluids built in. I'm sure the physx fluids will be in the future however. There's no reason you can't use a crapload of spheres to fake a fluid, but like johnny was pointing out, you're going to be limited by your particle count (65K)... which is not a lot of particles for fluids. But hey, if it's enough for your shot, and it looks right, then by all means use it. :D ...just a though.. maybe adding a negative keep apart would help create some surface tension

[JohnnyRandom]

sure, muthc more then 1 or 2 limitations but for small watery scenes its abilities are a new tool for a max user (better then glu3d in dynamic interactions) and cooperanting, again, also whit glu3d-PFlow operators we have other potentials...an evolving stuff vs a money expensive stuff like Real Flow.



in my tests I use for radius "collision shape size" and blob radius the same size and don't have mesh penetration.

Comparing a filling glass test using box#2 (A) and glu3d (B) I've noticed that the particle flow in A is too turbolent that in B cause upper particles crush bottom particles...if I resolve that then I'll post somewhat

Sure filling a round smooth glass, if that is what you need it for, if there are any concave or convex cornered objects within the fluid you'll get mesh interpenetration and it looks wrong. Try filling a box, unless your particles are minute in size, the corners do not fill properly, then you just lost the speed benefit because you have had to raise you particles counts through the ceiling. Anytime the particles get split by a collision object the mesh doesn't know any better.

As Solitude said if it works for you use it :D ;)

[PartiallyFrozen]

;)

20001 particles + box2 glue tweaked to all hell + 40min Cache to PRT + prt mesher = chocolate yummyness....

Box2 is cool!

Enjoy,
Mark


http://img28.imageshack.us/img28/572/box2fluidstest0091.jpg (http://img28.imageshack.us/i/box2fluidstest0091.jpg/)
http://img28.imageshack.us/img28/box2fluidstest0091.jpg/1/w1280.png (http://g.imageshack.us/img28/box2fluidstest0091.jpg/1/)

[SoLiTuDe]

Hey Mark, YOU SUCK! :D Haha... I just got back from drinking with you...and you suck.. or is that the alcohol talking? I dunno... I mean that's awesome. Nice to see that somebody make some decent looking fluids out of this. I wonder if you can show my realflow version...? Yours is better... in fact you should show it with the "kind of not chocolate" shader. :eek:

[jigu]

Really cool test. PRT mesher + Box #2 nice combo.

As I see it's chocolate and supposed to be thick fluid, I just wonder is it possible to make watery type of fluid with PRT mesher + Box #2? Something like carwheel splash? or For that, it might require more particles? and then it might be possible to make more particles by Partitioning in Krakatoa?

[JohnnyRandom]

Look who crawled out of the woodwork :D

[Heckle mode ON]
WTF Mark a still image? what are your a photog? where's the playblast?
[Heckle mode OFF]

Nice one, so what exactly did you cache to PRT, just positions? Did you just bring it back in to PFlow wit the PRT birth and updater?

[Bobo]

Look who crawled out of the woodwork :D

[Heckle mode ON]
WTF Mark a still image? what are your a photog? where's the playblast?
[Heckle mode OFF]

Nice one, so what exactly did you cache to PRT, just positions? Did you just bring it back in to PFlow wit the PRT birth and updater?

The PRT Mesher reads PRT sequences directly (in fact, right now it is the only thing it reads). We might add the ability to pick other particle sources (PFlow, legacy particles, geometry vertices, PRT Volumes etc.) in the future.

[JohnnyRandom]

Oh do tease! :drool:

[grury]

:cry: that PRT mesher looks/sounds very interesting.
When/will it be released into the wild?

[PartiallyFrozen]

Look who crawled out of the woodwork :D

[Heckle mode ON]
WTF Mark a still image? what are your a photog? where's the playblast?
[Heckle mode OFF]

Nice one, so what exactly did you cache to PRT, just positions? Did you just bring it back in to PFlow wit the PRT birth and updater?

Here is a link to the vimeo clip.

http://vimeo.com/6797861

enjoy!,
Mark

[noouch]

Looks nice! Still, 40 minutes to cache seems like a bit much for the result you're getting. I think I'll stick with "proper" fluid sims for now.

BTW I might be interested in the PRT mesher if you guys intend to sell it commercially and I haven't migrated to houdini by then ;)

[Bobo]

BTW I might be interested in the PRT mesher if you guys intend to sell it commercially and I haven't migrated to houdini by then ;)

Right now, it doesn't seem feasible to sell it as a separate product. What would it cost so people would be inclined to pay for it while actually making business sense for us? For example PWrapper is quite expensive for what it is IMHO. I don't expect people to pay the same or higher price for another tool that does the same, regardless of how much faster it is (and it is quite a bit faster in most cases, trust me). And then there is the free VRay only, render-time only plugin by Master Bercon. It does not offer all the flexibility of our solution, but it is free.
So right now it looks probable that it might ship as part of Krakatoa in a future update. When, and if at all, remains to be seen.

[galagast]

@PartiallyFrozen
- whoa! nice vid! i can't quite wrap my head around how you did that with box2 glue!

@bobo
"The PRT Mesher reads PRT sequences directly (in fact, right now it is the only thing it reads)"
- will it also read other particle channels like maybe adding a custom value for size? Then later be able to tweak those using a KCM?

"So right now it looks probable that it might ship as part of Krakatoa in a future update."
That would be an awesome addition to the arsenal. Count my vote in. :D

[Bobo]

@bobo
- will it also read other particle channels like maybe adding a custom value for size? Then later be able to tweak those using a KCM?


It does already. Internally, it is the component we use to turn Flood:Surf particles into meshes for rendering, but it is a lot more versatile than that. Oh, and it doesn't do just blob meshes ;)

[jigu]

I just can't wait for next Krakatoa updates.

Also does it work with mentalray? and it generates mesh at render times or can be viewed in viewport like pwrapper and blobmesh?

[Bobo]

I just can't wait for next Krakatoa updates.

Also does it work with mentalray? and it generates mesh at render times or can be viewed in viewport like pwrapper and blobmesh?

It works with anything and indeed generates a viewport mesh (with separate control for density). Not only viewed, but also modified - for Dragonball:Evolution, we had to add Volume Select and Relax modifiers to specific locations where the arms of the FuLums were coming out of the body to smooth the surface so we could model on top of it.

It can produce the same results as pwrapper and blobmesh in Metaball mode (just many times faster) and can work relatively efficiently with millions of particles, including overlapping ones. But now I am teasing... :)

[JohnnyRandom]

haha, thanks Mark ;) not bad at all...


@Bobo
Why can't I send cheeseburgers to Canada!

[savat]

in regards of fluids and physX...

http://www.youtube.com/watch?v=iyg9HgiD8X0

[3DMadness]

in regards of fluids and physX...

http://www.youtube.com/watch?v=iyg9HgiD8X0
It has been discussed in other thread that this is not physx fluids, that's real flow. It looks like a demo about something they want to achieve, since it also contains fumefx, rayfire and other fx tools.

Thread in cg news: http://forums.cgsociety.org/showthread.php?f=59&t=812801

[savat]

It has been discussed in other thread that this is not physx fluids, that's real flow. It looks like a demo about something they want to achieve, since it also contains fumefx, rayfire and other fx tools.

Thread in cg news: http://forums.cgsociety.org/showthread.php?f=59&t=812801

I'm sorry guys but the hope is the last to die...:)

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.