Combustion Solver Questions

I have started to play around a little bit with a combustions simulation - its very preliminary so apologies for any stupid questions.

I noticed that in the test scenes you general use sources from the Eddy primitives. I was trying to recreate some fire we had created here before, by using a VBD of a (kind-of) initial state. It looks a bit like this:

Looking at the Eddy test Nuke scripts, you could set a specific value for the various channels when creating the volume. For example temperature was set to 800.
When I tried to match these, I could only see a multiplier on the emitter connected to my VBD, and I couldn’t find a good way to check the resulting values that would be used by the simulation.

My question would be - is there any way to preview or sample those values (either in the emitter of the sim) and is are there any reference for what “good” vales should be for the different channels, and how they interact (fuel/temperature/density)?

I played with a lot of different numbers, wanting to get better “licks” of flames and I also noticed some things:

  • I had to use a very low multiplier for the buoyancy: 0.005 - is that to be expected?
  • Simply increasing the multiplier on the temperature emitter didn’t create bigger flames that I could see.

Perhaps some kind of tutorial or reference of how the physics of the solver work could be a useful guide for new starters (if there isn’t one already)…?

I can only post one picture at a time but I wanted to show my “progress”.
1st sim:

0001

Increasing heat and other tweaking:

0003

You can see the buoyancy problems.

Hi Rob,

before i jump onto this and potentially send you in the wrong direction, I was wondering if there is any chance you could share your nuke script ?
The combustion engine can be quite complex to master and a straight simple answer is not always easy to provide without seeing the issues/current setup.
Reason for this is that many of the parameters are quite tightly coupled.

By looking at your images, I assume the issue is probably that you have a lot of heat being generated causing a lot of upward motion. this is most likely by a lot of fuel burning off quickly at a high temperature. you can either lower the burn rate or the combustion temperature itself to release less energy.

I would love to see your script and I’d post the changes here so we can get this dialed in properly.
Working with fuel based emission is quite tricky and not always easy to work with. Eddy also allows you to bypass this directly and specify temperatures directly during emission. Instead of fuel you can emit the temperature ( eg ~1100 kelvin for firewood ) and smoke amount ( density ) directly.

We’ll put together a better guide for combustion fire setups soon. I totally agree it needs a bit more work and better examples to make it less complicated.

In the meantime if you can, please send the nuke script and I’ll have a quick glance over the setup.

Cheers,
Christoph

2 Likes

Hi Christoph,

sure - - it would be great if you could take a look. Its my first test of Eddy, so I’m sure there’s lots of opportunities for improvement you could spot in there.

I just have to look at the source VDB. As I mentioned, I took it from an existing simulation so its actually a pretty large file. I’ll work out a way of getting that over to you …

Cheers,

Rob

Hi Rob!
Thanks for supplying the data for us to have a look. Sorry for the delay, @christoph is also going to have a look soon at the script for a more detailed explanation, but thought I would jump in and show where I got to as well

I’ve tweaked your scene a bit to balance out a few parts.

and here’s the nuke script: https://www.dropbox.com/s/8dyfz3wcph5z5if/rnd_fx_Eddy_truFire_v003.008.nk?dl=1

Some notes and answers to a few of your questions:

  • The bouyancy should be set quite low for fire. 0.005 is fine.
  • Most of the bouyancy issues you had seemed to be too much fuel/heat. Shader was set quite cool, temp/fuel was really high.
  • we don’t currently have a diagnostic to read the values of your input vdb, but something like this is in our roadmap soon. The developers can probably elaborate on plans there.
  • I brought the heat and fuel down a lot, and also your velocity.
  • brought the shader temperature coeficient back up, these things are mainly what balanced it out.

Other things I changed

  • i added pressure iterations, and more timesteps in the e_element.
  • added motion blur

Suggestions

  • to cool it down a bit white balance should be tweaked a bit further
  • you can set the voxel size gain to 2 or 3 in the VDB Cache loader for faster speed, with little noticable difference.

Thanks for trying out Eddy, chat soon.

Cool - thanks for taking a look Matt. That’s much more what I was looking for.
I’ll spend a bit of time going through your updated script today…
Cheers!

Hi Matt - a couple of supplementary questions if you have a sec.
I have updated to your script - the values make more sense and I have the results more how I would like them, I was just wondering:

  • why you moved the rends into log space? I’m not much of a comper, so is there a reason you chose to work in this colour space in particular? In FX our output is usually in linear space.
  • is there a trick to caching and loading the simulation using the “e_” VDB nodes? I have had problems writing the simulation to disk and reloading for render, which would be more convenient for my render testing. I found I had to do the whole process at once to get reliable results.

Hi Rob,
I’m not sure what you’re seeing sorry regarding the log space, i didn’t adjust anything there to do with log. I also use linear for everything normally. Let me know if I’m missing something!

For using the VDB nodes, How i usually work, is add a E_Cache node and write out the sequence, then use a E_Vdb loader to load it back in. If its a script that I am re-using a lot, I’ll set up a switch node to go between these.

The only trick I’ve done before is to manually delete the existing acche files on disk, as we had a bug a while back where it wasn’t overwriting existing files correctly. I believe this was fixed but not 100%. Also out of memory will crash a cache, this is probably the most common issue I have here as its hard at the moment to gauge the memory until your sim grows to full bounds or dissipation.

If you can elaborate more on the unreliable results with caching we can help more there. Any feedback on these nodes I’m sure the devs would appreciate.

Cheers!

Hi Matt,

no that’s fine - the Nuke script came back with ‘Log_LUT’ enabled, I wasnt sure if that was significant. I know LUTs and the blackbody shaders can get a bit complicated.

Re. the caching issue - I’m not sure how well I can describe it:
I have set-up a similar network to the one you describe. I can use the cache node to write out the VDBs, and they seem to get written to disk fine.
Initially I could render the frames ok. However when I re-opened the script in a new session, I didnt seem to be getting the heat values from the cache.
Then to further confuse things, I tried to bypass the cache loader but then got no render at all, just an error like:

EddySceneFieldEmitter::test_input(0, EddySceneFieldEmitter::default_input(0)) is false!
Eddy[ERROR] - Render volume input density’ is invalid.
Eddy[ERROR] - Render volume input density’ is invalid.
EddyNuke[ERROR] - [EddyRender] Failed to create render state, not rendering

I then took the e_cache node out of the network entirely, but then got some error messages regarding memory - all a bit confusing.

This could well be user error, but it feels like it could be more straighforward (which I believe is something you guys are looking at). Perhaps something like the Houdini “fileCache” node would be good, where you can chose read/write/automatic, and perhaps a way of communicating the current “cache status” to the user.

Thanks,

Rob

Hi Rob,

there was a bug caused by the cache node that we’ve fixed in the upcoming build. To remove any doubt, I’d love to take a look at your scene and make sure its really gone and not something else. Sorry for the inconveniences. I agree that the caching needs to be more transparent to the user.

Cheers,
Christoph

No worries Christophe, thanks for looking into it. Once I have access again to double check my workings, I will send you the scene I was using via our FTP.
And re. the heat channel, looks like the e_channel I had for temperature in the shader got set to density instead, which I don’t remember doing…

Cheers,

Rob