I’ve read a few tutorials on how to create smoke (blender 2.5). I am trying to figure out the most basic set-up, after which I am free to experiment with various settings (such as those referenced in the tutorials) to improve the rendering.
I noticed that the tutorials I’ve seen all have to objects with smoke physics enabled: one as “domain” and one as “flow”.
I couldn’t render any smoke without creating a domain. Why is it necessary at all? Can’t the particles (smoke) be emitted in “open air” and left free to roam as far as their lifetime would allow?
Do an experiment. Set up a basic smoke sim in a small domain. Increase the size of the domain by say x1000 to simulate a small ‘real world’. Compare the two smoke simulations for quality and simulation speed.
Having blender limit what it needs to do all the neccessary calculations to a set volume is far more efficient than to wait the hours/days to do the calculations for a large/infinite volume.
The way the smoke is simulated is these particles are converted into cells in a 3 dimensional grid, and each cell has a different value of density, velocity, and heat; it’s not a particle based fluid sim, it’s just using particles to define where the smoke enters into the simulation, ie. at the start of every frame, every cell that contains a “flow” particle will have its density increased by however much you’ve set it to, and some velocity is thrown in there too if you’ve got it setup for that.
A few tips:
To make a domain, make a new cube, and change it ONLY with translation and scale.
DO NOT use negative values for scale.
DO NOT make changes to the cube in edit mode. It may seem to work fine, right up until you need to render. Then the texture space is messed up and you get this weird tiling effect with your smoke data.
EDIT: I will say this: I wish there was an option for a sort of “dynamic” domain. You wouldn’t setup a domain, it would just automatically expand as needed. This could save time and hard disk space (though probably not save the coder a headache!)
Thanks to both. You mean that for each single frame of the render, the density values (and other data) is calculated for each of the 3 dimensional cells in the whole domain (inc. those cells apparently not including any smoke, i.e. those far from the emitter during the first few frames)? That’s a lot of data crunching, indeed!
P.S. @LazyCoder Nice clone effect on your youtube channel!
Well it is optimized a bit so that empty cells don’t take as long to process as full cells that are actually doing something. They also don’t take up as much space as there is a light amount of compression on the caches.
Take for example an explosion I’m working on: base of 64 res, then EIGHT high res divisions. Total cache size: >120GB. No typos here. Bake time: somewhere around 4-5 DAYS. All this for a photoreal smoke simulation that lasts about 12 seconds @ 30fps @ 1920x1080.
What LazyCoder said is mostly correct. But the particles don’t convert into cells, the amount of cells is defined by your low resolution smoke divisions and the particles are just there to emit smoke and “fill the cells”
For example: 48 Divisions on a cube where every edge has the same length has 48x48x48 cells = 110592 cells.
But I think you meant that and I just misunderstood it, or you wrote it too difficult g
But for a basic setup just go with a normal cube as domain and a 2D plane as emitter. That’s the easiest way to go. For everything else you have to do some math and/or trial&error. Start low (24 divisions) find the right amount of particles, set all the values on your settings and then increase your divisions. When you double your divisions, you have to multiply the amount of particles by 4 because you will have double the cells on your emitter so you need more particles. That’s only with a 2D plane that uses 2 Axes. A 3D emitter would use 8 times the amount of particles.
I wrote a little tool to help me calculate that stuff, because if you don’t exactly double it, you have to do some math g
Resizing the domain:
You have to be careful, not only because of the bugs LazyCoders mentionend. When you just scale your domain up by 2 and change nothing else, you have to double the divisions to get the same amount of detail. More complicated are things that involve scaling along one, or two axes. The amount of divisions just set the cells for the longest axis. Let’s say you have a cube as domain and you scale it along the z-axis. The 2mx2mx2m cube becomes a 2mx2mx4m cube. It has double the height than width and depth. Your 48 divisions cube just lost 3/4 of his cells! Instead of 48x48x48 it only has 24x24x48 now. Instead of 110592 cells, you only have 27648 cells left. That’s because the cells will always try to get a cube like shape. In that case you would have to go up to 96 divisions to get 48x48x96 (the same resolution you had before).
And yeah simulations take a lot of space on your hard drive. For small things around 20-30gb should be enough (for testing and stuff). On higher settings 100gb and for final products a 1TB hard disk should be fine. Hard to say without knowing how long the simulations should be and what settings you’ll use. But a good thing is, Blender 2.5 will go on even when your hard disk is full It’ll produce 0kb frames, but you can still use what is already baked.
@LazyCoders: I don’t think Blender 2.55 can make photorealistic smoke (at least not fire) yet. But you can convince me of the contrary
8 high divisions is propably way too much. I don’t even see a difference between 2 and 3. And every step increases render times by…4? or was it 8? Well it was a lot g
It’ll produce 0kb frames, but you can still use what is already baked.