HYBRIDO is the name for the new fluid technology delivered within the RealFlow version 5, it stands for HYBrid large dimension LiquiD solver.

Transcription

1 HYBRIDO WHITE PAPER

2 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

3 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 Concepts within HYBRIDO 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 Concepts within HYBRIDO 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 F.08 Grid mesh with displacement

6 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 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 A case study, the lighthouse 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 A case study, the lighthouse 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 A case study, the lighthouse 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 = 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 A case study, the lighthouse 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 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 A case study, the lighthouse 11 F.17 Grid mist and paremeters It took 1 hour in a i7 to simulate the mist for 500 frames 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 A case study, the lighthouse 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 A case study, the lighthouse 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 A case study, the lighthouse 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 IDOC IDOC IDOC IDOC 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 hours

15 A case study, the lighthouse 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 A case study, the lighthouse 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 A case study, the lighthouse 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 and ask for a demo version and try out all these new features. Thank you.

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