volume fill problems, concrete and temp channel for fluid

[Tony_Morev]

yes, all of the above!

1) Volume fill up problem: fills up to about half and never past it, no matter how much i pour into it.
2) Is there any way to make fluid act more like concrete or mud - thick and dense yet flowing? No matter what i try it still seems too "watery" and the stream hitting the standing volume creates too much turbulence. Also if i viscosity is set too high it stops moving at all and just overflows instead. I'm looking for something that would stick to objects but still have flow-able amount of friction within the matter. In the process of experimenting i found that some kind of collision surface roughness of stickiness setting could be helpful (like in RF or Blender).
3) It wasn't until Mike showed how to make fluid using fuel channel that i got any fluid working at all, and it was my impression that temperature channel SHOULD work. What's the step-by-step of making the temp channel fluid?

thanks!

[Ivaylo Katev]

1 - about the fill up - i would recommend conservation 60/smooth, advection step 2, classic advection, start with this settings and see the spf value. then you can constrain the spf value using the limits, if you need settled water after the pouring.
2 - use the viscosity (there is a sample)
3 - all the channels should behave equally as liquids, however the temperature is slightly faster, but requires more attention during the setup. this attention is needed because the temperature by default is set to values used in the fire/smoke simulations . you have to change the default source value to 1 (it's 2000), the surface level to 0.5 (it's 1000), and the preview options to value 0.5-1.5 (by default is 1000-10000). this are the additional actions needed when temperature is used as liquid.

[Tony_Morev]

thanks for the super quick reply Ivaylo!!!
one question though, which "sample" are you referring to for viscosity?

[Ivaylo Katev]

open My Documents/Phoenix FD/samples, the scene is called visc.max

[Tony_Morev]

oh, Great! so i'm not crazy after all, i'm just missing some files cause i ran render-slave install thanks again Ivaylo!

[Tony_Morev]

so, the fill-up is still a problem
60 didn't fix it and on top of that i now have the flow stuck half way down the spout ...
i'll have to play with it more when i have time

as a side note ...
looking through this thread http://www.chaosgroup.com/forums/vbu...flow-and-shape
i can't help but sympathize with Brett's frustration
as much as it hurts to always have your product compared with something else, it's the best way for us users to express ourselves
and so, by comparison with "other" simulators Phoenix's setting seem esoteric at best
there's very little "human" language involved and too many things in need of "developing a feel for"
even the help file isn't helping much
in working with RealFlow for example rarely does anyone need to open their help file wondering what this or that parameter will do

i understand that Pjoenix wasn't born a fluid simulator and what i does with fire it does very well
but you seem to be persistent in adding fluid features to it, so clearly you intend it do be a true fluid simulator one day
may i suggest splitting off the UI for fluids into a separate module all together, so the metaphysical parameters of gas simulations are no longer part of the workflow

[Tony_Morev]

is it safe to use time scale and higher than normal gravity?

Also, Ivaylo, you said to set the conservation to Smooth while you the visc example it's set to Bidirectional
setting it to Smooth along with the rest of the settings didn't fix the fill up issue ... Bidirectional on the other hand seems to be working for the fill-up, but the manual discourages from using it for stability reasons, where's the truth in this?

thanks!

[Tony_Morev]

i just ran into a good example of what i mean by metaphysical parameters
"approach steps"
in normal everyday language related to fluids i would guess it's how far i'm standing from a glass of water

so? ... let' s look in the help file .... "the cycles of condensation performed at each simulation step" ...
hmmm ... what you're explaining here is the role of the parameter in you calculation process
but i don't know the math you're using behind the scenes and i don't need to know it
i AM however interested in how this setting will affect my simulation, which the help file doesn't explain

this is what makes the learning curve a bit steep, instead of learning Phoenix a user has to "feel" it

just venting, never mind me
i know it's hard enough to program something that complex, let alone translate it later into dummy-user language for the manual

[Ivaylo Katev]

i agree with you, not only you are complaining, definitively we have to work in this direction. but in general i'm skeptical about the possibility to reach the easiness of the realflow or fume fx for many reasons well, let return to the technical questions
can i see your scene with the fill up problem? usually the problem have the opposite form - the liquid level rises up too fast and continues to fill even after the source is stopped. perhaps i'm missing something.
and may be this parameter "approach steps" should be removed from the user interface. until now it has no reasonable application, always the best result is achieved in one step (that really surprises me, but c'est la vie ). so forget about it, just keep it 1.

[Tony_Morev]

not sure you are being too modest about your abilities or if you’re telling me the math behind Phoenix is so advanced that English vocabulary will most likely fail at describing it

In any case v-ray went through these steps already, at first the manual was no more than a bunch of notes taken in the process of coding and the defaults were off, but after a while the defaults are great, the presets work nice for those who don’t care much for reading the manual, and those who do the manual is VERY helpful. So, you guys have enough experience in shaping up a product to be user friendly

Now, on to what I personally think can make the biggest impact on the ease of use …

The fluid simulator needs it’s own UI that has strictly fluid related settings. Start a new simulation a count how many different things need to be changed before you can run a fluid sim. All of that stuff needs to be the defaults. Your current simulator UI is fine, leave it for gasses, just make a clone of it, call it Fluid and clean it up plus change the defaults. If you insist that different channels produce the same results then ditch the rest of them and hard-code the Temp in to run the simulation. Then do the same for the source portion. I see you’re adding splashes and foam, those don’t even relate to fire and smoke simulations, so keep them strictly in the fluids UI.

Another example of how things can be made more user friendly.
No matter how many times I tried the default color curve always delivered too bright of a fire. The fix mostly consists of moving all the points down simultaneously, so why not put an “exposure” slider in the UI that does just that and collapse the curve into a button. This is just me and other users may prefer to not have a slider, to make an educated decision get some feedback: run a poll or consult a group of trusted users regarding the questionable tweaks.

[Ivaylo Katev]

interesting topic
coincidently or not today vlado gave us a lecture about the user friendliness
actually i agree with almost that you said. some of your suggestions are already discussed and some of them will be realized in the future. of course not everything can be improved. for example if you have good name for the "advection method" in human understandable language then i will buy you a beer!

[Tony_Morev]

interesting topic
coincidently or not today vlado gave us a lecture about the user friendliness

I feel for you

In itself ADVECTION is not too scary. It's much more frustrating to deal with the settings it offers. Take SPF for example, everywhere i've looked you refer to one or the other method of determining the settings some of which come down to a user looking at the calculation progress and then inputing the new limits based on what the solver showed. Isn't solver part of your program as well? Why not do a quick pass for a minute and get the numbers back from it automatically. There has to be a way, either first couple of frames or reduced cell sampling of some kind. Call it "analyzing" so users don't think it's frozen and run it in the beginning of the simulation. Assuming of course that you can't find a better dynamic "during-the-simulation" solution.

If you insist, however, i think a good way to lower the intimidation factor of ADVECTION would be to step aside from physical terms and simply call it a "property transfer (method)"

I think this all comes down to you trying to do too many things in one UI. For gases advection implies more than just mass transfer, in fluids of equal temperature however it would refer to mass transfer alone. So, the real solution in this particular case i believe would be to finally decide on which method applies to what type of simulation and reduce the UI (UIs) accordingly, so advection disappears from the UI altogether. Fluids use one type, gases another. And if you find better algorithms later, test them on volunteers first and then just hard-code them in for the release versions, to keep the bulk of users form going insane.

if this was helpful in any way, you can keep the beer
i'm a rather unorthodox russian - i don't drink

[Ivaylo Katev]

i think a good way to lower the intimidation factor of ADVECTION would be to step aside from physical terms and simply call it a "property transfer (method)"

can't disagree with this!
however, i don't agree with your suggestion about spf calculation . usually you have nothing to do with the spf, it's automatic, the limits are intended to be used as prevention from unexpected situations not for regular cases. to use them in a prety normal simulation is a new concept that arose during the attempt to achieve ideal flat settled liquids. really the spf mechanism of phoenix is very complicated compared to the other simulators. for example particle flow has also spf parameter, but it can be chosen between few fixed values. phoenix has 3 parameters involved into the spf calculation. however, this has its reasons. for example if we are using constant spf value like in pf, then when you switch between coarse and fine grid resolution the simulation result will be extremely different! from this point of view, the complicated spf mechanism actually simplifies the work.

[Tony_Morev]

that's ok
just keep in mind that every setting you have in the UI needs a layman explanation in the manual ... with pictures
and the more mutually dependent feature sets you have the harder it'll be to properly explain