WaterBlobs

#21

Blair,

I’m afraid this is a bit rough and not at all pretty, yet, but here you go :slight_smile:
http://homepage.mac.com/cake_or_death/watercaustics1.mov

Ian

#22

Ian
Your water looks like very frozen vodka (yum!) and the caustics looks good. The liquid looks a bit like sirup, i think… is RealFlow?
Nice
I hope, someday we will can to import huge flows to EiAS… The Bryan plugin is a big help BTW.

FelixCat

#23

Hey FelixCat!

Can you even freeze vodka? :slight_smile:

It’s supposed to be water!? The liquid is far too viscous but the simulation times get prohibitive (I’d have to leave it overnight to do it properly).

Yeap it’s realflow, what impressed me the most is that this simulation previews in realtime in openGL WITH transparency preview enabled. Very impressive :slight_smile:

I’ll improve it if/when I have time,
Ian

#24

From what we’ve read here we understood: we should not think about “EI water”, our particle systems are busy with other, more important things/tasks and such little interior details as fountains etc. are out of their attention. Instead we must learn how to use RF. Ok, thx, clear

BTW:Vodka freezes below -30 (one of Igors is from Siberian).

#25

hi igors, all,

i have read all of this with interest.

take a look at this:
Schwall02_mp4.mov

please pay attention only to the motion of the spheres as a whole. it is a dirty hack, sure, but i wonder how this looks with blobmaker. mr. blobby is crashing, btw.
a setup similar to this would solve the volume problem. well, it would need lots and lots of small spheres, but i am sure some genius mind can take the idea and make something more workable out of it, he? :slight_smile:

#26

Hi, Uwe

Impressive movie! BTW: we heard iphysically a jet’s behavior is very similar to rigid body. But liquid needs more “basic spheres/units” (not too much but we cannot hope for something rational with 100 blobs only). Of course it’s possible to replace each sphere with set of blobs (how about to use WM to check this?) but it would be as “march of separate water parts” :slight_smile: Water needs a particle system, IMO that’s unavoidable

#27

right, water needs particles, but the particles need some form of self-collision so they keep their volume and affect each others movement. imho, thats the main reason particles systems perform so poor (or hard to handle/setup) right now.

rodeo is obviously not the right answere to this in its current state, but it is leading in an interesting direction.
my idea would be a specialized rigid body solver that is optimized for “virtual” spheres (no need for polygons, so it can handle way more of them) together with a blob generator that is
capable of dealing with more than a few hundred particles (maybe some form of adaptive meshing).
thinking of it: the rigid body solver could be adaptive, too. if one particle is surrounded by other particles, they all act as one (keeping the volume). more to the edges they break into pieces until a user-definable threshold is reached (again keeping the volume). the blob generator somehow knows about the volume of each particle, so small blobs are possible until they again reach a user-definable threshold, after that only particles are rendered as spray.
sounds good?
i am sure there are more things to be considered (like gravity and all that stuff), but i think a system with this attributes would make very nice fountains (and other, more dramatic, things).

#28

Uwe, a sentences like “a specialized rigid body solver” sound really awful :slight_smile: cause they are associated with something “big, solid and needs months of work”. We think in real practice the things are much simpler. Look at water splashes for example. Each dropped blob generates a circular wave, these waves should interacts with “secondary” (reflected) blobs. Complex task? Well, not “a piece of cake”, but IMO absolute realistic and interested for us. However, the problem is that before starting we must to write a big part of particle system: emission, numerous particles options etc. etc. And all becomes to be hard, big and heavy :sad:

#29

  1. by the way, everyone is talking about rf, which undenieable has its strength for fluids and dynamics, but has anyone tested the Blender 2.4 fluids and the possibility to get them into Eias, as far as I know the comunitys of most of major apps, already tried or figured out to make plugs to use those opensource fluids in their own Program.

  2. Hi Uwe, for me as an softwaremaking ignorant all you think about the potential of rodeo sounds quite promissing to me as the the rodeo-demos-movies do.

Thinking on the announced RF4 here is another (as it seems to me desperate) need for Eias, RF4 would cover if ever we could use it for more complex-simulations:

Since we have Fiber-Forge which has alot for a real nice animated 3d-Hairs, until now those Hairs don’t have any real dynamics and collission detection.

Might this be one of the “other, more dramatic, things” rodeo will do one time?
Steffen

#30

We are not familiar with Fiber Forge to discuss what it can/cannot do. Our attempt in this area was Trooper. From our experience we can say: we would be happy to have accurate and fast hairs/fur WITHOUT any real dynamics and collision detection. Unfortunately it’s IMO impossible with phong render.

Same for water: all these cool liquid physics look too big, and, IMO, too far away from EI. Our proposition was to have a normal simple fountain first.

#31

hi igors,

please take a look here:

Thread at ramajc Forum

in theory, is something like this possible from your point of view?

#32

Hi, Uwe

We are familiar with XP-server and the first XP-client plug-in (ParametricSurface) is already on our surgery table

(it’s a quote from other forum)
We cannot see how XP and Rodeo can help here. Inside particle system it’s only 1-2 hours of work to create an external block of data in format we described in this thread. But in other ways it’s practically inaccesible: how to “read velocity”? How to know which point is which at previous frame? Creating “another one particle system” and duplicating numerous particle options is a thing we try to avoid (without luck though :slight_smile: )

#33

Hi, UweWe are familiar with XP-server and the first XP-client plug-in (ParametricSurface) is already on our surgery table
uhh, great! :slight_smile:

We cannot see how XP and Rodeo can help here. Inside particle system it’s only 1-2 hours of work to create an external block of data in format we described in this thread. But in other ways it’s practically inaccesible: how to “read velocity”? How to know which point is which at previous frame? Creating “another one particle system” and duplicating numerous particle options is a thing we try to avoid (without luck though :slight_smile: )

doesn’t the “data block” contain some form of ID for each particle? isn’t the velocity the difference between the current frame the one before?

in my little mind game the particle system would only supply the initial steps needed (particle distibution, speed and direction). this would be feed into rodeo (via XP-server). rodeo turns the particles (internal) into spheres and does the dynamics and collisions.
nice and easy (for the user :slight_smile: )

i am just thinking how to get the best of both worlds together without the need to build all into one plugin (a paradigma that you planted into my mind) :slight_smile:
XP-server just seemed to fit into this picture.

and i like the idea of more 3rd party developers working together with their individual strengths.

edit: of course all of this would require a joined effort of you and jens/patrick.

#34

That’s a very rough velocity estimation :slight_smile:

Hmm… we’ve serious doubts that manipulations with thousands of spheres is sooo easy for user :slight_smile: And (even more important) rigid body dynamics cannot help for liquids dynamics, they are very “different dynamics”.

EI plug-in can pass data to other plug-ins/shaders, so there is no any necessary to use much more complex XP-server mechanism. But overview you are on right way, sure :slight_smile:

BTW: we notice “a strange effect of Rodeo” - looks like anything should come WITH collision detection, physical engines etc. etc. Otherwise - it’s too little and doesn’t deserve our attention (we think only globally). But do you really need such cool physics? Your movie (last posted here) is very impressive, but let’s imagine a water stream instead of balls. Uwe, do you plan a “Titanic-2 film”? :slight_smile: If so, you need a specialized tool with price like $10K as minimum (don’t forget us if it happens). But how about more modest, more practical, utilitarian water effects? And (also important) with cheap price. Who said that “collision detection” is the center of this universe? A year ago we observed carefully all movies that EI artists done with RF. It’s very noticable: all is going perfectly and amazed in closed volume, like water/juice fills a glass/cap. But in “architecture area” (fountains, waterfalls etc.) successes are much more modest. Thus we aren’t sure RF should be an etalon to copy.

#35

That’s a very rough velocity estimation :slight_smile:

what should i say? me = math genious! :wink:

Hmm… we’ve serious doubts that manipulations with thousands of spheres is sooo easy for user :slight_smile: And (even more important) rigid body dynamics cannot help for liquids dynamics, they are very “different dynamics”.

in my imagination this should be exactly as easy as every particle generator with thousands of particles.
and to be honest, i don’t know the differences between rigid and liquid dynamics and i don’t really care. for me it has to look and feel right.

the only reason i brought this idea up here, was this little rodeo test movie i showed you. the movement was close enough to liquid to get me thinking how this could get better and, first of all, better managable.

BTW: we notice “a strange effect of Rodeo” - looks like anything should come WITH collision detection, physical engines etc. etc. Otherwise - it’s too little and doesn’t deserve our attention (we think only globally). But do you really need such cool physics? Your movie (last posted here) is very impressive, but let’s imagine a water stream instead of balls. Uwe, do you plan a “Titanic-2 film”? :slight_smile: If so, you need a specialized tool with price like $10K as minimum (don’t forget us if it happens). But how about more modest, more practical, utilitarian water effects? And (also important) with cheap price. Who said that “collision detection” is the center of this universe? A year ago we observed carefully all movies that EI artists done with RF. It’s very noticable: all is going perfectly and amazed in closed volume, like water/juice fills a glass/cap. But in “architecture area” (fountains, waterfalls etc.) successes are much more modest. Thus we aren’t sure RF should be an etalon to copy.

well, it’s like christmas: you play with the new toy and think of ways to use it until it breaks and the next big toy comes around :slight_smile:
and no, it’s not the centre of the universe, but it is fun and interesting enough to keep me thinking in what direction this could be used, besides the obvious.
throw something shiny in my direction and i will bite :slight_smile:

there was a time when 3d was dominated by huge, expensive SGI maschines. then came the desktop with flexible and cheap software. you know the rest of the story.
igors, i don’t want you to be cheap, but very flexible :slight_smile:

and again, this is just an idea we are discussing, nothing more.

#36

Hi, Uwe

When we see your movie, the first our mind was: smoke explosion! The balls’ behavior is quite “exponential” (as explosion needs). Also: explosion (unlike water) doesn’t require tons of blobs, often several tenth (or less yet) are absolute enough. And again: 90% are really done (like Brian wrote), but, alas, we’ve no solutions for rest 10% :sad: The “smoke blobs” should ultimately come together, joined, a “separate blob” momentary ruins all composition. And that is what rigid body dynamics wont do.
So, yes, the movie is interested, but… the distance to final goal is same long :slight_smile:

#37

Blair/ Igors,

How about that data packet then?? :slight_smile:
Ian

PS. Uwe, what you are describing sounds very much like ‘dumb water’ which looks fine for very simple stuff (not too detailed/ distance shots). It’s much quicker to calculate this kind of fluid in RF (sorry to bring up RF again :wink: i’ll do a couple of simple sims tonight to show the difference between what you’re proposing and ‘fluid dynamics’.

#38

Hey Guys,

Ok, first, let look the best fluid simulator these days:
http://www.flowlines.info/gallery01.html

second,
I did this simulation to one of my Beer’s TV adv. with RealFlow, for us… poor FX artists which dont have acess to simulators like Flowline… RealFLow is really good… waiting realflow 4.

http://homepage.mac.com/tegger/iMovieTheater7.html

In the Other side, I agree with Igors when they are trying to add the basic water simulation to basic effects in EIAS, but like in one of the answers here… if Igor’s water plug-in could work in layers with other plug-ins… we could make our simulations more complex.
The Uwe animation in a artistic point of view using Rodeo is close to a splash of water in a hall, but I agree with Igors, the simulation need more elements to be a realistic fluid simulation.
We (EIAS users) need complex fluid simulations, SURE, Why? in my case… any new TV adv today want the best of FX saw in feature films… TV adv is a mirror of Films.
I almost get a complex job 2 months ago which I wanted to help Blair in improving his Free RealFLow Plug-in with no luck… the client denied the TV adv. idea, but I still waiting the chance to improve it, adding a option to RF plug-in import to EIAS the Individual Particle Data, so, then you could link a Blob plug-in or a Ubershape Sphere, making a wave of sand or in my case a wave of a Clean Product.

Thankssss
Tomas

#39

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.