WaterBlobs

[Igors]

Hi, Ian

I am curious, can you share you 50k blob fountain?

Sorry, but no, a promo of BM features is not a goal of this thread. We can say only there is a little benefit from large muscles without a portion of brain

[halfworld]

Okay, fair enough. Going back to your first post, interaction between particles would be the major missing link. Seeing blobs push each other around (force away from the emitter) does the trick.

Not to talk about BM too much, but in the sample movies it doesn’t seem to have this ability.

Ian

[Igors]

Hi, Ian

Okay, fair enough. Going back to your first post, interaction between particles would be the major missing link. Seeing blobs push each other around (force away from the emitter) does the trick.

Not to talk about BM too much, but in the sample movies it doesn’t seem to have this ability.

Ian

Metaballs have only vertices and facets of linked child groups. That’s too few data to organize any pushing

[NorthernLights]

Maybe I missed something in this discussion but I’ve got a free plugin for importing RealFlow meshes into EI and exporting animation data from EI into RealFlow.

That having been said I’d like to see somebody do something cool in RealFlow and render it in EI with Caustics.

[halfworld]

Hey Blair,

Yeap, your great free plug-in does the trick for very simple simulations, but anything complex simply crashes the Plug/EI.

I emailed you an example of this a couple on months ago… I can resend if you want…

Basicly, if you want to have a fountain, that’s fine, but if you want to have a realwave (for a splash or fluid flowing into a pool etc.) then you’re talking over a million polygons per .bin, the plug-in can’t handle this (you just go into a terminal loop/spinning beach ball).

A possible solution is to export .objs from Realflow instead of .bins and convert to .fac and fact cycle in EI, unfortunatly batch conversion from .obj to .fac doens’t exsist in Transporter and isn’t practical in OBJ2FAC (yet!). This would be the prefered method because .bin files don’t contain normals, but once converted to .fac you have normals, so renders are several hundred percent faster.

I’ll do you a movie with caustics this week
Ian

[Igors]

Maybe I missed something in this discussion but I’ve got a free plugin for importing RealFlow meshes into EI and exporting animation data from EI into RealFlow.

That having been said I’d like to see somebody do something cool in RealFlow and render it in EI with Caustics.

We talk not about RF but about how to coordinate particles+blobs in EI to make “RF here”. Accurate and step by step (no loud declarations)

FACT FORM linked to particle plug with ‘SETD’
The tags are:

• ‘SPED’ - speed - 3 floats per point
• ‘MASS’ - energy - 1 float per point
• ‘PRID’ - unique ID - 1 ulong per point

That’s enough for our first adagio with blobs

[halfworld]

Blair,

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

Ian

[FelixCat]

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

[halfworld]

Hey FelixCat!

Can you even freeze vodka?

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

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

[Igors]

Hey FelixCat!

Can you even freeze vodka?

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

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

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).

[bronco]

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?

[Igors]

Hi, Uwe

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,

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” Water needs a particle system, IMO that’s unavoidable

[bronco]

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).

[Igors]

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).

Uwe, a sentences like “a specialized rigid body solver” sound really awful 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:

[fahl5]

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.

rodeo is obviously not the right answere to this in its current state, but it is leading in an interesting direction.
…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).

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

[Igors]

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.

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.

[bronco]

hi igors,

please take a look here:

Thread at ramajc Forum

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

[Igors]

Hi, Uwe

please take a look here:

Thread at ramajc Forum

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

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

particle system emits some particles (maybe even some more, hehe).
XP can read the position and velocity values and pass it on to rodeo.
rodeo turns them into virtual spheres and does its magic.
the final output would be particles for use with some blob generator

(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 )

[bronco]

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

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 )

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 )

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)
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.

[Igors]

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?

That’s a very rough velocity estimation

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 )

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

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)
XP-server just seemed to fit into this picture.

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

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”? 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.