GSoC 2012 - Smoke Simulator Improvements

Hi,

I’m going to work on improving Blender’s smoke simulator as this year’s Google Summer of Code project. Work will happen in the “Fried Chicken” branch.

A basic summary of project goals:

  • Fire Simulation
  • Integrate simulation data with “Force Fields”
  • Moving domain support
  • Smoke color support
  • New smoke emission types
  • Other Improvement

You can read details from the project wiki page where I’ll be also updating my weekly progress: http://wiki.blender.org/index.php/User:MiikaH/GSoC-2012-Smoke-Simulator-Improvements

Any questions, suggestions and feedback are welcome. :stuck_out_tongue:

Mikaah,
dynamic paint is so awesome; i have no doubt that you reach your Gsoc goals…
Wish you all the best.

I will be keeping a very close eye on this, and am very excited!

Good luck!

Aside from general speed improvements, I would beg that you label the settings in such a way as they make sense or at least a hover-over dialog that really describes what each settings is. Too many of these simulations have impenetrably named settings. I’ve heard it’s due to what the actual mathematical formulas require for input, but that’s not helpful to Joe User like me.

Will u implement automatic dynamically re-sizable domain along with moving domain? I’ve seen this feature in other soft. It will help to reduce render times of volume materials and also will reduce baking time.
Real fire simulation will be a great feature. Thanks for adding this on your list.
Wish you all the best.

Great thing! the Smokesim is one of my favorit parts of blender :slight_smile:
So if you ask vor sugestions i have one:
Is it Possible to improve the Smoke Preview so that it shows more than only smoke densety, such as Heat and Velocity?
edit:
Smokedomains that have more than 8 Vertecies would also be greate but i think there are limitations in the Physik Libaray.

woooo sounds amazing!
I hope you can finish your job in time and than merge to trunk :slight_smile:

That would be awesome but probably too complex to do in one summer. Still happy to know the project is in good hands

Would this work apply to cycles as well?

more than one domain, and domain bleeding(mixing where the domains overlap)…is this plausible?..the first is already possible I think…not sure though.

@Freemind:
cycles does not support volume rendering yet.

yeah, so you could have a series of torches!

Will u implement automatic dynamically re-sizable domain along with moving domain? I’ve seen this feature in other soft. It will help to reduce render times of volume materials and also will reduce baking time.
Real fire simulation will be a great feature. Thanks for adding this on your list.
Wish you all the best.

speed improvements

+1

Is it Possible to improve the Smoke Preview so that it shows more than only smoke densety, such as Heat and Velocity?

I believe Viewport FX GSOC will help for that king of feature, not sure it’s directly related to Smoke sim

No, that would be very complex to add for grid based simulator. Usually when software has dynamically scaling domain, it’s actually just a bounding box for particle based simulation. :spin:

Multiple domains / smoke simulations are already possible. “Domain bleeding” wouldn’t work because simulation grid sizes or resolutions had to match perfectly.

That should be possible. Only real issue is how to visualize such 3D data. Even domain edges have some heat so color visualization alone would make it impossible to see what’s inside the domain. And if it gets too complex, is it really worth it. :eek:

Ok was only a suggestion and i think it would only realy help at bug hunting or to figure out why are the smoke behave weird.
One other suggestion Multireszones:
One predefinde Zone in the domain gets an higher resolution than other parts of the domain. That could reduce the wait for an preview or could help to have one Smoke simulation for bigerarears.

Dynamic Paint is the proof of your coding skills! Good Luck for this project MiikaH! Thanks again.

Nope. I suggest you take a look at Houdini’s smoke and pyro solver or FumeFX or Phoenix FD from Chaos Group. They all offer dynamic scaling for their voxel based simulations. At least in Houdini’s Pyro solver you also usually don’t specify the number of grid cells but instead a single floating point value which represents the cells size on each axis which results in grid cells having always a cubic shape and that’s what you usually want anyway.
The other advantage of one single floating value is that it’s easy to control, not very abstract and you don’t waste resolution on one axis e.g. when you have a very tall container.

Anyway whether you intend to implement any of the features found in fumeFX or Houdini’s Pyro2.0 (afaik the most used tools in VFX industry) or not you still should really take a look at those tools to at least get an idea of where Blender’s smoke sim should head.

went to youtube to watch some onion news. and there’s already progress uploaded, awesome.

But there are builds of cycles out there with a volumetric patch. Which might mean volume rendering isn’t too far off. So finding a way for the volume information coming from smoke to communicate with how volume information is read in cycles might be a reasonable thing to look into.

That said, I’m no a coder. And I’m thrilled to see there are smoke improvements on the horizon.

Excellent! Best of luck on this project!

One question: is the integration of the simulation data with force fields meant to allow the smoke simulation to affect other simulations, and not the other way around, or is it also meant to allow other elements (like force field objects) to affect the smoke and not just the emitting particles?

I think I will watch this project the most this GSOC.