Niagara Fluids : Injecting scalar fields from external data sources

Hi there,

I was wondering if there is an easy or straight forward method to inject scalar grids (density, temperature, pressure) and vector grids (velocity) into Niagara-Fluids simulation from external datasets. I am able to externally generate ASCII grid files or even generate volume textures from scalar values in a 3D grid, but how do I use them in initiating Fluids simulations? Any idea?

Besides, is there any method to inject a vector field in the simulation grid? I am particularly interested in simulating the effect of wind on the advection of scalars and vectors in the simulation. I calculate actual wind fields in an external software and export them as ASCII grid files, FGA files or volume textures.

Thank you for any help!
David - Gnomusy

2 Likes

Likewise. It would be great to have user-defined scalar fields as well.

I would also love to be able to sample the temperature field once it has been calculated, per frame. I’m waiting on the Epic sales team to confirm if it’s possible or not. :slight_smile:

1 Like

Hi all.

Well, I’ve been doing some further research on the methods used in basic fire/smoke simulations with particles in Fluids plugin and I’ve found some interesting things, in particular some limitations to be aware of if you want to use them for realistic simulations:

  • The concept of ‘temperature’ is used rather to separate the scalar part of the gas that is smoke (called ‘density’) from that which is flame (called ‘temperature’), but there is no direct interpretation of physic temperature as it is in the real world.

  • A threshold is established to separate what is smoke and what is flame with temperature values close to 0.02, which roughly corresponds to the threshold of 500ºC in the real world, which is more or less true.

  • I have deduced an approximate relationship between the temperature values in the system (x) and the actual temperature in the real world (y), expressed in ºC, taking as reference the colors used in the black body curve for values beyond 428ºC. This approximate relationship is:

                  y = 5228 x + 428.72 with R² = 0.9854
    
  • FLUIDS It is not a complete thermo-fluid-dynamic model, for example, it does not take into account the relationship between pressures and temperatures, or between temperatures and densities. In short, little is added about energy (heat) transfer.

  • There is no real diffusion of density or temperature, just dissipation (decay) over time.

  • It does not incorporate the mass as a function of the density or vice-versa, it assumes in all the calculations that mass is always the unit.

  • The viscosity component is not considered as a force, rather something is incorporated as a factor for the dissipation of velocity as a function of time.

  • The application of buoyancy positive forces due to temperature and negative sinking forces due to density follow the direction of the vector g; with this, if we describe a conservative gravitational field, the effect of temperature and density will exclusively follow the vertical axis. That’s why the simulations come out so straight up, there is little lateral expansion.

  • There is no real diffusion function, rather an asymptotic dissipation function (decay) is applied, which is a function of time, not as iterative function of the values of the neighboring cells.

  • The pressures are solved using an iterative Jacobi method, which is very efficient if the GPU is used. In my tests I have seen that better approximations were obtained with 10 iterations (instead of 6 as suggested in the videos).

  • Turbulence is not really solved, only Perlin noise is applied at different frequencies, which visually is convincing. So, little is added to the real dissipation of mass, momentum and energy due to turbulent movement.

  • The pressure units are expressed in Kbary (Kdyn•cm-2); mass in Kg; length in cm; speed in cm•s-1; force in Kdyn (Kg•cm•s-2); surface in cm-2 and time in s. These are guessing, no official documentation on units used in UE.

  • The divergent-free velocity is calculated from the divergent velocity field and the pressure gradient, using Helmholtz decomposition. The pressure field is used, therefore, as an intermediate calculation but not as a final physical result that can be used.

  • The initial border conditions of pressure and temperature are set to 0. In my simulations of the real world, I consider pressure to be 1 atm (around 1000 Kbary), and temperature to be 20 ºC. It would be great to set up also initial conditions of wind as part of the velocity vector field.

Therefore, I find it difficult (but not impossible) to incorporate temperature, pressure, and velocity boundary conditions (for example, vertical profile of the atmosphere in the boundary layer) into simulations that demand to be more realistic, since these parameters are not taken into account in the simulations. Nevertheless, new modules can be written specifically for this.

Well, It is not my intention to criticize these models, which I find awesome in most situations for game development, but I would rather like to underline the limitations that I have been finding for those who intend to do simulations based on physics (as is my case). Also, there are the components, the modules and the flexibility to write ad-hoc custom modules if necessary.

Despite these comments, I find the plugin to be very interesting and promising, especially the relationship between simulations and the ability to inject the results into Ray Marching-based materials, something we’re looking forward to very much.

If you find out more about how Fluids works, I would be super happy to learn about your findings, approximations and results.

Cheers

David–Gnomusy

2 Likes

Wow, that’s a deep analysis! I can’t find anything wrong with what you say.

I got an answer back from the Epic sales team, and it was not yes, but not no at the same time. I basically didn’t get a definitive answer.

Of course, I could always alter the source of Unreal Engine itself, but I don’t want to go there. We should be able to sample temperature and density from Blueprints, even if it suffers from slow copying from GPU RAM to CPU RAM. It’s not like I’ll be copying the whole thing all at once. What is the point of having a system that cannot be sampled? It’s just pretty (oh so pretty), but otherwise useless.

1 Like