hybrido - RealFlow

Transcription

hybrido - RealFlow

HYBRIDO
WHITE PAPER
HYBRIDO - White Paper
Introduction |
2
1 INTRODUCTION
HYBRIDO is the name for the new fluid technology delivered within the RealFlow version 5, it stands for HYBrid laRge dImension
LiquiD solver.
Up to now it was difficult to make realistic fluid simulations for medium to large scales using RealFlow. The main problem is the
particle-based approach that RealFlow uses for solving the fluid equations. This approach is good for achieving the detail needed for
splashes, but for simulating the core of the fluid where no detail is required you still need to use a lot of particles. This is possible,
but the simulation times for this number of particles is long.
The best approach to deal efficiently with the core simulation of the fluid is to use a grid-based solution. A grid is created in the
space where the simulation is going to take place and the fluid equations are discretized and solved at the grid points. However this
approach is not adequate enough to catch the fine detail needed for splashes - a super high-resolution grid would be needed to
resolve the fluid where the fine detail is needed.
There are approaches and techniques to separately alleviate the problems of particle-based and grid-based methods, but in our
opinion the best way to deal with these limitations is to use a hybrid model where the grid-based approach is used to solve the core
of the fluid and a particle-based approach is used to solve the splash.
HYBRIDO is a novel technology that combines a grid-based and particle-based approaches to deal with the complex task of
simulating medium to large scale scenes. Other phenomena (also known as secondary elements) that are typical of large scales like
foam, mist and fine surface detail (displacement) are also addressed with this technology.
As an example, In figure F.01 below you can see a screen shot of a typical simulation that can be created with HYBRIDO. All the
simulation data was rendered with Mental Ray© using the new version of the RealFlow RenderKit tools.
F.01 Domain size is 100x20x60 meters
© Next Limit Technologies 2010
Concepts within HYBRIDO |
3
2 CONCEPTS WITHIN HYBRIDO
Grid domain
This is the space where the simulation is taking place, i.e. the computational grid.
F.02 Grid domain
You can have as many domains as you want in a scene but they don’t interact between them.
Grid emitter
This is the source of the fluid. The emitter must be attached to an object and this object defines the volume from where the fluid is
created. In the lighthouse scene we have the main body of the water and five additional objects from where the crashing wave will
be created.
F.03 Grid emitters
4
Grid splash
The splash is generated automatically when an under-resolved region of the grid-based fluid is detected. The splash node is similar to
the particle-based emitters so actually you can have all the flexibility RealFlow provides for this particle-based approach. For instance,
you can attach any daemon to the splash, or you can change the behavior of the particles from fluid to dumb, there is no limitation.
F.04 Grid splash
The representation of the splash node is just a box. This box delimits the volume from where the splash is going to be generated,
i.e. only under-resolved regions inside this box will generate splash. The splash particles won’t be removed when going outside the
box, they will be removed when they cross the surface of the grid-based fluid and coming from the “air”. It is important to note that
splash particles don’t add mass to the grid-based fluid, i.e. there is no coupling between the particle-based fluid and the grid-based
fluid. Instead of that foam will be generated.
Grid foam
Texture-based and/or particle-based foam. Foam is generated when splash particles enter the grid-based fluid surface coming from
the “air”. In the texture-based approach a gray-scale image represents the foam, in the particle-based approach particles represent
the foam. When using the particle-based approach for the foam you have the same flexibility than you have for the traditional
particle-based emitters, so actually the foam particles can be simulated as a particle-based fluid.
F.05 Particle-based foam
5
Grid mist
Mist is the white cloud of water droplets that are formed because of the splash particles breakup process. Splash particles are tracked
to detect when the breakup process is taking place. When the condition for breakup is met, the mist is generated at that point and
the mass of the splash particle that is lost is transferred to the mist field. Once the splash particle is under a threshold mass the splash
particle is removed from the simulation.
F.06 Mist is generated from the splash particles
Grid mesh
This is the node that represents the surface of the grid-based fluid using a polygonal mesh. Normally you are going to be interested
in the generation of a displacement to add detail to the mesh surface. This displacement data is generated in the grid domain node
but it is shown in the grid mesh.
F.07 Grid mesh without displacement © Next Limit Technologies 2010
F.08 Grid mesh with displacement
A case study, the lighthouse |
6
3 A CASE STUDY, THE LIGHTHOUSE
3.01 SETTING UP THE GRID DOMAIN
We start by importing into RealFlow the lighthouse geometry, then we create a grid domain where the simulation is going to take
place. For the lighthouse we used a proxy geometry in order to avoid a high count polygon model. A high count polygon model will
make our simulation run more slowly so whenever is possible a low count polygon model is desirable. Once the geometry is in the
scene we create a “Grid Domain” node, then we transform this domain so it encloses the region of interest of our simulation.
F.09 A grid domain and Fluid parameters
For the moment we can leave the default parameters for the grid domain. This will allow us to run simulations very fast and to check
very quickly if the setup has been created properly. Please notice that in the figure above the parameters are not the default ones,
they are the ones used for the final simulation.
The most important parameter is the “resolution”, basically it is the approximate number of the cells the grid will have. Having
many cells will create more accurate simulations but at the expense of larger simulation times. Another important parameter is
“compressibility”. This parameter is mainly responsible for a fluid’s tendency to bounce. A value of 0 means that the current fluid
cannot be compressed anymore so you can eliminate any bouncing effect, but it takes longer to perform such a calculation. For our
scene it is important that the fluid doesn’t bounce at all so we set a value of 0.08 for this parameter.
3.02 SETTING UP THE GRID EMITTERS
We are interested in having a main body of water and a couple of emitters so we can reproduce a wave that is moving forward to
crash against the lighthouse. There are several ways of setting this up, for instance, you can just create the main body of water,
then create a plane that is going to be used as a shaker and animate this plane using a sinusoidal function. The approach we ended
up taking is to have several emitters with an initial speed. This approach gave us the crashing wave we were looking for easily and
quickly.
7
To setup the grid emitters you must first import the geometry that is going to be filled with the fluid. Grid emitters always need an
object to emit from. For the main body of water we set an initial speed of 1 m/sec in the direction of the coast, the emitter node has
an arrow that indicates the emission direction. A “jittering” value of 0.3 will disorder the initial location of particles, useful to avoid
patterns in the fluid.
F.10 Grid emitter for the main body of water
To create the wake emitters, we just create several instances of the “capsule” built-in object, scale and place it to configure an
irregular wave. The initial speed is different from one emitter to another. Also notice that we animate the parameter “Stream” - when
this parameter is activated the emitter is producing fluid all the time. We are interested in stopping the emission at a specific time.
F.11 Grid emitters for the creation of the wave
8
3.03 SETTING UP THE FORCES (DAEMONS)
For the moment just adding a default gravity force is enough. A kill volume daemon is needed to remove fluid that is reaching the
coast. Notice that a regular kill volume daemon can be used with a grid domain. We are not interested in having the crashing wave
bouncing off the coast once it passed by the lighthouse. In the figure below any fluid coming into the green box will be automatically
removed.
F.12 The Kill Volume daemon
3.04 RUNNING THE SIMULATION
We are ready to start our simulation. As explained before it is good idea to start with low values for the resolution parameter. After
several tests we were happy with a value of 1,000,000. Actually this resolution is very low, but you will be able to create a highdetailed simulation once the secondary elements, splash, foam and mist are added. The simulation took roughly 5 hours in a i7
machine for 500 frames (20 seconds).
F.13 Grid domain simulated
9
3.05 ADDING A GRID MESH
The mesh can be created from the cached simulation data. It is interesting to create the mesh before the generation of the secondary
elements because mesh and the secondary elements must match perfectly. The most important parameter here is the “Detail
threshold”, and please notice that this parameter is also listed in some of the secondary elements. The reason is to provide a way of
making secondary elements to match with the mesh. The “Detail threshold” parameter for the grid mesh indicates how much you
want the mesh to fit the fluid based on the under-resolved regions. The under-resolved regions will be used to generate splash (as
explained in the next section), so you don’t want to generate a mesh for those regions. In the picture below see this parameter in
action. The particles you can see from the simulation that are outside the grid mesh are under-resolved regions therefore not used
for the mesh generation. It took only 1 hour in a i7 machine to build the mesh for the 500 frames.
F.14 Left, detail threshold = 0.2 | Right, detail threshold = 0.0
3.06 ADDING SECONDARY ELEMENTS, THE SPLASH
One important thing to bear in mind is that once the grid domain has been simulated you can use it in cache mode to generate all
the secondary elements. From a base simulation (the grid domain) you can get many different variations of your secondary elements.
The splashes are created at under-resolved regions. Detecting these regions and seeding fluid particles on them is a computational
intensive task. Most of the times you want to restrict the detection of those regions by adjusting the splash bounding box. In the
figure below only splash will be created in those under-resolved regions inside the bounding box.
F.15 Splash bounding box
10
There are many parameters that allow you to configure how the splash will be created and what properties it will have once created.
F.16 Grid splash parameters
One important parameter is “Detail threshold”, it can have a range between 0 and 1 and it’s a very “technical” value, connected to
the grid’s resolution. As mentioned before, the fluid engine is always looking for under-resolved regions. If the solver has detected
such a zone, HYBRIDO refines the grid internally to produce the fine splashes. “Detail threshold” can be seen as the sensitivity of this
process. With 1, it can detect almost any under-resolved region in the scene, while 0 only produces splashes in zones with a high
need for detail.
One important addition in RealFlow version 5, which is actually not part of HYBRIDO but can help when trying to get splashes, is the
new Sheeter daemon. This daemon is specially conceived to create thin layers of fluid from just a few number of original particles. In
Figure F.07 above this daemon was used to get splash layers around the lighthouse.
For the final scene we created several splashes and placed them in some strategic places in the scene. We then used the new
IDOC (Independent Domain Of Computation) concept and the new RealFlow Job Manager to compute them at the same time over
a network of machines. The chaotic nature of the splashes allow us to compute them without considering their interaction, for this
reason they can be computed separately and at the same time. We will talk more about this new IDOC concept at section 3.8.
It took 9 hours in a i7 to simulate the splash for 500 frames.
3.07 ADDING SECONDARY ELEMENTS, THE MIST
Once the splash has been calculated we can use the cached data to create the mist. It is important to compute the mist before the
foam because the process of mist generation fragments the splash particles so they might disappear before entering the grid domain.
A splash particle not entering the grid domain won’t generate foam, that’s why mist should be computed first.
Mist is produced when a fluid droplet is fragmented into smaller droplets. This fragmentation process is known as “droplet breakup”
and is characterized by the ratio between aerodynamic forces and the droplet’s surface tension. Large water droplets have weaker
surface tension forces compared to aerodynamic forces, so they have an increased chance of splitting into smaller droplets. Though
we’re talking about droplets here, it’s important to know that mist cannot be exported as particles. In RealFlow, mist is the graphical
representation of a density field and hence completely different from splashes.
By default the mist is generated in the “Unbounded” mode, this means mist will be generated in all the grid domain. Usually you
might want to have it in the “Bounded” mode where you can place the mist and specify the region of interest and make of the most
of the resolution.
When a mist is linked to a splash emitter the splash particles are being fragmented and its mass transferred to the mist. Once the
radius of the splash particle is below some threshold the particle is removed. This means that the mist is actually changing the original
splash. When using a splash in cache mode we don’t want to modify the original splash sequence. To avoid this, the mist detects
when the splash is in cache mode and generate a version of that splash sequence. In the display properties of the splash emitter
you will find a parameter “Fluid” where you can choose whether to see the original particle sequence “Primary” or to see the version
that the mist is creating.
11
F.17 Grid mist and paremeters
It took 1 hour in a i7 to simulate the mist for 500 frames.
3.08 ADDING SECONDARY ELEMENTS, THE FOAM
Once the splash and mist have been calculated we can again use the cached data to create the foam. This way you don’t have to
simulate again and again your splash if you are happy with it, just use the cached data to setup your foam.
Foam can come in two flavors, particle-based or texture-based. When the splash particle enters the grid domain it creates a foam
particle or seeds a foam value in the foam texture. For particle-based foam, notice that even if you have a displacement (more about
displacement in the next sections) the foam particle is properly placed. For a particle-based foam, a mesh can be created and textured
giving quite realistic looking foam.
It took 8 hours to simulate the foam, including the mesh, in a i7 machine for 500 frames. Please notice we are just talking here about
the particle-based foam. The texture-based foam was not used for the lighthouse.
F.18 Particle-based foam with a mesh
12
An initial state for the foam can be created from user images so you are not just restricted to the foam created by the splash particles.
Foam can be texture-based as explained before. To be able to see it in the RealFlow viewports you need a grid mesh. Please note
that the algorithm to simulate particle-based foam is totally different than the texture-based one, so if you simulate both they won’t
perfectly match. The texture-based foam is based in a diffusion-dissipation algorithm where the particle-based are just regular
particles advected with the velocity field of the fluid at the surface.
F.19 Texture-based foam
3.09 IMPROVING SIMULATION TIMES, THE IDOC CONCEPT
IDOC stands for Independent Domain Of Computation, it can be used to optimize the simulation times. Depending on your scene, and
normally when we are talking about big scale simulations, you can always divide your scene in different regions that don’t interact and
therefore can be simulated at the same time. The chaotic nature of splash when going to large scale give us the freedom of simulate
different regions at the same time. The main simulation must be done before in a single machine, but the rest of the secondary
elements can make the most of using the new IDOC nodes.
The IDOC is a special node represented in the user interface with a box, this box encloses the region that is going to be simulated
when this IDOC is active. In the lighthouse scene there are four IDOCs, see them in the figure below.
F.20 IDOCs
13
For every IDOC we have created splash, mist and foam nodes. The panel of nodes looks like the figure below. Please notice that the
main simulation node GridFluidDomain01 is also included.
F.21 Nodes per IDOC
Every splash box is placed to match the box of the IDOC. This means that if you simulate only that IDOC, only splash particles are
going to be generated at that box. Simulating every IDOC at the same time is possible even if the different splashes are not going to
interact. For large scale scenes this interaction can be avoided, of course it depends on the scene and you might need the splash to
interact, in this case all of them must be in the same IDOC. For the mist and foam, by default, they are created in the “Unbounded”
mode - this means that foam and mist will be generated in all the simulation region and NOT just in the IDOC box, but because the
foam and mist are generated from a specific splash there is some kind of limitation of what is being produced in every IDOC. In figures
4, 5 and 6 you can see the results from the simulation of the IDOC 2.
By setting the parameter “Simulation” of very IDOC from “Active” to “Inactive” you can decide what to simulate in your scene but the
real power of the IDOC shows up when is used together with the new job manager. In the IDOC panel there is a button “Send to job
manager” that automatically configures the current scene and sends it to the job manager.
F.22 Job Manager interface
14
In the figure above you can see how four jobs have been scheduled, one for every IDOC. As soon as there are job nodes available
the simulation jobs will be started.
One remarkable feature of the new Job Manager is the possibility of using an heterogeneous group of simulation nodes solving
automatically from a user given rules the paths of the different resources used by your scene. In our case we have Linux, Windows
and Mac simulation nodes, the scene was stored in a Linux machine named HUYGENS. We set the path translation rules shown in the
figure below in the scene before sending it to the Job Manager.
F.23 Path translation rules
When the Job Manager sends a job it knows if the simulation node is Linux, Windows or Mac. Depending on that it will replace the
“Prefix” string in the scene path with the platform string, making possible to load and simulate the same scene in all the supported
platforms.
In the table below, the simulation times for the secondary effects is shown (time is given in hours). Because all the IDOCs were
simulated at the same time we can see that the most restrictive IDOC is IDOC2 taking 18 hours to simulate.
Splash
Mist
Foam
IDOC1
5
1
6
12
IDOC2
9
1
8
18
IDOC3
5
1
5
11
IDOC5
7
1
7
15
Simulation time for IDOC2 plus the simulation time for the grid domain plus the generation of the grid mesh will give us the total
simulation time for the lighthouse scene when using IDOCS.
Grid Domain
Grid mesh
IDOC2
Total Time
5
1
18
24 hours
15
3.10 RENDERING
All the rendering was done using the RealFlow RenderKit (RFRK) rendering tools. These tools allow you, for instance, to create highresolution polygonal meshes from the particles at render time. You can also render particles in a volumetric way to mimic the mist
effect. A displacement tool is also provided to produce at render time the displacement created by the Grid Domain.
There is RFRK for MentalRay™ and RenderMan™ . In this case the render was done in one pass with MentalRay™ and all simulation
data was rendered using the RFRK. Please notice how the huge amount of simulation data was rendered in one pass thanks to the
RFRK management of memory.
We used the RFRK_Mesher to create a mesh around the foam particles at render time, in the figure below please notice how the foam
detail can be captured using a mesh. Because the foam particles are displaced using the displacement from the simulation, the foam
mesh and the grid mesh plus the displacement match perfectly.
We used the RFRK_Cloud to render the splash and the mist. The splash can be rendered using a mesh just as we did for the foam
but it seems that a volumetric render of a huge amount of particles where they are very close to each other gives more appealing
results. In the case of the mist it is quite obvious that it should be a volumetric render.
The grid mesh was exported from RealFlow as a sequence of BIN mesh files that can be imported into the most important 3D
packages using the RealFlow plugins. In this case we imported the sequence into Maya™ and used the RFRK_Displacement to
displace the grid mesh and get the final look you can see in the figure below.
F.24 Lighthouse rendered using RFRK
16
In the figure below we present some comparative tests of the RFRK_Cloud in action with different values for the “opacity” parameter.
F.25 RFRK_Cloud opacity tests
17
4 CONCLUSION
We have presented the key points of the new HYBRIDO technology, but we have only scratched the surface of what is possible with
this new technology.
In RealFlow version 5 we have created a new rigid and soft body solver (named CARONTE) with the aim of simulating many objects
in an efficient way. A new concept has been introduced in the body solver, the “MultiJoint”. With MultiJoints you now have a modern
and sophisticated way to connect bodies.
The coupling between CARONTE and HYBRIDO opens up many new possibilities when dealing with large scale simulations.
Go to www.realflow.com and ask for a demo version and try out all these new features.
Thank you.
© Copyright 2010 Next Limit SL
RealFlow a registered trademark of Next Limit SL
All trademarks included in this catalogue belong to their respective owners
All images in this book have been reproduced with the knowledge and prior consent of the artists concerned and no responsibility is accepted by producer, publisher, or printer for any infringement of
copyright or otherwise, arising from the contents of this publication. Every effort has been made to ensure that credits accurately comply with information supplied.

hybrido - RealFlow

Transcription

Similar documents

sports splash pots - Gila River Casinos

Lebus summer furniture show

splash city invite2013 for web.indd

SKYLAKE SIONS

Strongbox by Airfloat Systems

Splash - Margarete Roeder Gallery

Styrofoam Recycling - Village of North Aurora

Soft landing

Water World Tips for Families

German cushioning specialist Hukla is one of the