Why Realflow doesn't have a container?

lukeiamyourfather
Posts: 2880
Joined: Mon Oct 15, 2007 4:09 pm
Contact:

Why Realflow doesn't have a container?

Postby lukeiamyourfather » Mon Jan 11, 2010 2:22 am

Vitor Teixeira wrote: Thanks a lot Albert for having the time to give that.
I really appreciate your help.

Luke I talked with Robert Bridson he told that the product will probably will be available to buy in the next summer to Mac and Linus, with support focused on Fedora versions similar to Maya. Is Fedora a lot different from Ubuntu?
Cheers

Well, yes and no. Fedora and Ubuntu are very similar to the end user. The big difference I see is the development philosophy. Fedora is basically Red Hat Enterprise Linux beta. Everything that works in Fedora eventually becomes RHEL. Because of that Fedora can sometimes be unreliable and can break compatibility because they push innovations early and use Fedora as a test platform. Also Fedora is completely free software so things like video drivers and multimedia codecs are not available in Fedora repositories, philosophically and legally a logical move but a pain for the end user. Fedora release life cycles are typically about a year before the repositories are no longer online and you need to upgrade. In that sense Fedora is a poor choice for a large organization like a visual effects studio, despite that though many studios are using Fedora because of the support from developers. Probably because Fedora is a logical stepping stone for developers since most CG software was originally meant for use on Red Hat (e.g. Autodesk), but people don't want to pay for Red Hat.

Ubuntu is developed for the average Joe with as many bleeding edge features as possible but without sacrificing reliability and user friendliness where possible. Ubuntu is also not completely free software but that means things like proprietary video drivers and multimedia codecs are available in the repositories which are more user friendly and convenient. Its based on Debian and in the eyes of the CG community Debian is nothing more than a web server and hardly anyone supports it or takes it seriously (e.g. Autodesk). Though it seems to be gaining more support in recent years. Ubuntu repositories are online and with security updates for at least 18 months and up to 5 years for the long term support release (LTS). In theory this would be a perfect choice for visual effects but the lack of support from software vendors makes it difficult to implement.

There are other technical differences like RPM packages versus Debian packages (DEB) but those are easy to adjust to. Things that should be considered when choosing a distribution are support length (how long are the repositories updated for), official vendor support for software used, ease of use and maintenance, cost of support if support is needed, and so on. There probably won't be a single distribution to meet all your needs but try to pick one that meets most of them. Cheers!


User avatar
Vitor Teixeira
Posts: 312
Joined: Thu Jul 23, 2009 1:47 pm
Location: Porto, Portugal
Contact:

Why Realflow doesn't have a container?

Postby Vitor Teixeira » Mon Jan 11, 2010 4:11 am

I see.
Thank you kuke

User avatar
Vitor Teixeira
Posts: 312
Joined: Thu Jul 23, 2009 1:47 pm
Location: Porto, Portugal
Contact:

Why Realflow doesn't have a container?

Postby Vitor Teixeira » Fri Jan 15, 2010 2:37 am

tmdag I'm not understanding something.

"Numerically, the Lagrangian viewpoint corresponds to a particle system, with or without a mesh connecting up the particles, and the Eulerian viewpoint corresponds to using a fixed grid that doesn't change in space even as the fluid flows thought it." From Robert Bridson.

The mesh free method enters in the Lagrangian method or is it the "combination" or not between Eulerian and Lagrangian?
From what I can understand from Robert, this method enters in the Lagrangian method.
Is this right?


After lots and lots of reading I still with another doubt I'm sorry.
Can someone make me understand, probably I know the answer but I'm not quite understanding after so many names in my head, why Eulerian (good for fluids, bad for solids) grid based solvers are better for fire and smoke and Lagrangian (bad for fluids, good for solids) mesh free, particle based are better for water ?

User avatar
tmdag
Posts: 1023
Joined: Thu Jun 28, 2007 2:22 pm
Location: New Zealand
Contact:

Why Realflow doesn't have a container?

Postby tmdag » Sun Jan 17, 2010 9:45 am

mesh free is Langarian method

Langarian and Eulerian are methods developed for fluids. For solids simulations there are different algorithms.

I cannot tell You what method is better for what kind of fluid sim because everything depends on situation. For eg. if You want to create crown splash - You know that Heightfield (2d fluid representation) is not enough because there can be only one point in Y. So You can choose Grid based or particle based method - Grid based method would need BIG detail for crown-like look but It would be much easier for filling container (eg glass). With particle based method it's easier to achieve crown like look (because for eg. each particle could represent single drop) but You would need enormous number of particles to fill Your container. So In such situations You could mix two methods.

That's why We use Heightfield method (realwave) for ocean sim and SPH for splashes on that ocean.


I don't have too much experience with fire sim but as You can see on FusionCis site - they have created fire and smoke sims on RF's SPH.
Sometimes is about simplicity of fluid representation. With particle based fluids You would need to create mesh for Your sim and then apply volumetric shader.
With grid based fluid You have different approach.
Sometimes is about memory usage and speed of Your simulation. In Grid based method it can be used 2-dimensional flow field instead three dimensional and this way You gain speed and less memory usage

But with both methods You will achieve similar effect.

As I don't have much experience with fire/smoke and this is interesting topic, I'll digg some more technical info.
"Do not feed the trolls"
Albert 'tmdag' Szostkiewicz
FX Technical Director
Weta Digital

User avatar
Vitor Teixeira
Posts: 312
Joined: Thu Jul 23, 2009 1:47 pm
Location: Porto, Portugal
Contact:

Why Realflow doesn't have a container?

Postby Vitor Teixeira » Sun Jan 17, 2010 8:31 pm

Great, great.
I'm studying also.
I'll have to dig a bit also to get proper answers

Anaxarchos
Posts: 843
Joined: Wed Mar 19, 2008 4:21 pm
Contact:

Why Realflow doesn't have a container?

Postby Anaxarchos » Mon Jan 18, 2010 9:29 am

Hola Vitor,

for a better understanding of SPH for CG I strongly recommend you reading

"Particle Based Fluid Simulation for Interactive Applications" by Matthias Mueller et. Al.

It's an abstract and you can get it here in an HTML version.

Most other sources are not free, but I guess you university has access to sites like ACM:

http://portal.acm.org/citation.cfm?id=846298

For Grid based methods, I think Stam's abstract for GDC 2003 is most helpful as Stam is very good in explaining things:

http://www.dgp.toronto.edu/people/stam/reality/Research/pdf/GDC03.pdf

Realflow in fact, also uses a grid in order to locate the particle's positions in space. The wider the particles are spread in your scene, the bigger is this grid (thus the amount of memory reserved for the grid). You can watch this in those cases, where the simulation "explodes" (stuff goes wrong and partricles wildly shoot throgh the scene). RF then resreves loads of memory in order to represent such a big scene and if this exeeds youtr machine's memory, the application will crash.
www.fk-fx.com

User avatar
Vitor Teixeira
Posts: 312
Joined: Thu Jul 23, 2009 1:47 pm
Location: Porto, Portugal
Contact:

Why Realflow doesn't have a container?

Postby Vitor Teixeira » Mon Jan 18, 2010 2:09 pm

Well that about RF is new.
Never thought it had a grid to calculate that.
This is great info
Thanks a lot

Anaxarchos
Posts: 843
Joined: Wed Mar 19, 2008 4:21 pm
Contact:

Why Realflow doesn't have a container?

Postby Anaxarchos » Mon Jan 18, 2010 2:54 pm

Well, there has to be at least some mechanism for determining a particle's position in space....it's more some kind of local coordinate system for the particle cloud what differs from the OpenGL world coordiante system. I guess it's nor used for solving, but maybe there's some small contribution. NextLimit don't mention any details on the solver's implementation. They call their method "XPH", standing for eXtended Particle Hydrodynamics
.
Another reason why there has to be a local coordinate system (thus a grid) for the particles:
If the particle cloud had no local coordinate system, activating "xform particles" and moving the particle cloud around, wasn't possible at all.
www.fk-fx.com


Return to “RF4: General topics”

Who is online

Users browsing this forum: No registered users and 1 guest