Community
Bifrost Forum
Welcome to the Bifrost Forum. This is the place for artists using Bifrost to ask and answer questions, browse popular topics, and share knowledge about creating effects procedurally using Bifrost. You can also visit the Bifrost Community on AREA to download an array of ready-to-use graphs, read Bifrost news and updates, and find the latest tutorials.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

combustion performance

6 REPLIES 6
Reply
Message 1 of 7
suryamunny
1294 Views, 6 Replies

combustion performance

as i said before in the beta forum combustion performance is really slow and its a big problem for an awesome solver it was letdown by its performance.i am hoping to see performance improvements for combustion and overall aero system very soon after the episode1 release.
6 REPLIES 6
Message 2 of 7

Did you see this software? I want to cry,xddd. I can't understand nothing. This guys promisses realtime...how is possible looking to Piro and Aero running?

 

https://cgpress.org/archives/embergen-real-time-volumetric-fluid-simulation.html

https://jangafx.com/software/embergen/

 

Message 3 of 7
pyroskat
in reply to: juanjo_bernabeu

I hope to see a performanceboost in aero other solvers in bifrost at some point. 

About Embergen... Its a techdemo so far, lets see the finalproduct. To start it says so far only exports sheets and flipbooks, meaning is not storing or writing any volumedata yet.... that sometimes its taking as much time as the simulation itself, so here maybe you have the answer of why its so fast.

Message 4 of 7
juanjo_bernabeu
in reply to: pyroskat

Sorry for the offtopic.

For me its perfect. 

 

Let me work with fluids in realtime to iterate faster and test attributtes and later you can spend all the day saving the caches if you want... They key is the creative procces, why all the render engines go for GPU and realtime viewports?

 

Anyway, if you work with Pyro or Aero, when you hit play without saving, you need to wait a lot. I think everybody knows that, xdd. Dont get me wrong, I love both, 🙂 But its surprising that other tools can get it.

 

Other example is Eddy for Nuke, or NukePoint Render, from Mads Hagbarth.

Message 5 of 7
mspeer
in reply to: juanjo_bernabeu

Hi!

 

"But its surprising that other tools can get it."

It's mainly about software optimization  + used hardware.

If you create an application that calculates and displays only one thing, there is a lot you can skip at code.

Also by making a simulation less realistic (or stable) you can save a lot of time for the calculation.

At the linked video i can't see how versatile the software is and what all can be simulated. Also the hardware that was used to create this is not mentioned.

 

The displayed movies are impressive, no doubt, but if you could use this software to create the simulations and output that you want and need in your production environment, that's a completely different issue.

Message 6 of 7

Thanks for your feedback! We are continuously improving the speed of our solvers and there are still many opportunities for optimization.

 

I have posted a few tips on how to speed up aero and combustion simulation times below. For example, you can adjust some of the settings on the aero_solver_settings node and/or take advantage of the ability of the aero/combustion solver to represent certain regions of space at coarser resolution -- like away from camera, in the interior of smoke plumes, where there is low detail in the voxel_fog_density, during pre-roll etc. See here for inspiration: https://www.youtube.com/watch?v=eAXhE4-AMkI.


If there are simulations that exhibit particularly poor performance, it would be a great help if you were able to share the scene/json file along with a few notes on stats as well as what your expectations to simulation times are for the particular scene. We might be able to suggest alternative parameter settings and can use the scene file as a benchmark in our optimization work.

 

AERO SOLVER SETTINGS:

(1) Take as few sub steps as possible (lower max_steps on the aero_solver_settings node)
(2) Use simulation_bounds on the aero_solver_settings node to confine the simulation within a certain region of space, as by default a simulation will not be clipped and expand wherever there is smoke. Alternatively, use voxel_fog_density dissipation to ensure the smoke does not expand over a large volume. Tiles allocated can be visualized with the volume_scope from the rebel pack.
(3) Bifrost version 2.0.2.0 includes an optimization for cubic interpolation (the styles wispy,busy,fluffy on the aero_solver_settings node). Generally these styles lead to higher quality results, but are also more expensive than the smooth style (linear interpolation).
(4) By default Bifrost uses a higher order improved time integration which leads to higher quality and more lively simulations. This improved time integration gives superior results over the usual first order time integration but also makes the solve more expensive, so if you need a faster sim you can turn it off on the aero_settings node inside aero_solver_settings.
(5) If you're using huge colliders but don't need to sample them at the finest resolution, you can increase the "detail size" on the collider node. Similarly you can increase the "geo detail size" on the source node.

 

SPATIAL ADAPTIVITY:

(6) If some of your sources are further away from the camera or don't require the highest resolution, you can represent them a coarser resolution by increasing the fluid_detail_size on the source_air nodes. Note that this can be done per source and sources at different resolution can co-exist and interact.
(7) Apart from the control of resolution on the source_air nodes, the adaptivity is controlled via the aero_adaptivity node which should be connected to the adaptivity port on the simulate_aero node. Please refer to the inline documentation of the node for more information. Note: enabling adaptivity may not always speed up simulations if the chosen adaptivity settings do not lead to enough reduction in simulation data. Furthermore the viewport rendering currently adds an overhead for adaptive simulations.

 

COMBUSTION SETTINGS:

(8) Enabling radiative heating (by setting radiative_heating > 0), is an expensive computation. Turn if off if not required for your simulation.
(9) Diffusion (of oxygen and temperature) is also an expensive computation. So set their values to zero if you don't need them. For example, if you're not using soot oxidation and your burn rate is larger than zero, you may not need oxygen diffusion.
(10) Explosions/volume-expansion can produce large velocities that in turn trigger more sub steps. If you don't need volume expansion for your simulation, set expansion_scale to zero.

 

MISC:

(11) Only cache out to disk if required as disk IO is expensive. An alternatively is to render the simulation directly without disk caching.
(12) Evaluating fields can be expensive. Only use the ones you need.
(13) If the simulation starts to run out of memory, simulation times can increase dramatically. If this happens you can reduce memory usage by enabling adaptivity as well as lowering the resolution of the simulation and/or of the voxelized colliders and sources.

 

Cheers,
Michael



Michael Nielsen

Principal Engineer
Message 7 of 7
feriferari13595642
in reply to: mspeer

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report