City is a displaced plane, using a texture created with JSPlacement.
The foreground smog is a smoke simulation, which I will probably redo with finer resolution. There is a single smokestack emitting, but the plume from that is really too faint to even see. So I’d like to make more smoke plumes and get them dense enough to be visible, while not making the general smog so dense that the city is lost.
I had thrown in some random emission points to act as lights. I liked the idea, but the implementation wasn’t right… so I removed them in the compositor, and lightened up the scene. Now it’s bright enough we wouldn’t expect lights to be powered on. I need to think of a good way to add decent looking windows/lights in all the ‘buildings’.
This was a quick sketch, figuring out a usable workflow. Blender really doesn’t like working with high poly counts, so this was a chance to practice setting up proxies.
Let me know if you have suggestions to take this further. I think the scene has some potential.
I baked the smog at 256 resolution (boy was that slow!), extended the city out a few blocks, and worked on the lights on the buildings.
Somewhere in there, I lost the world lighting. The background color shows (the orange sky), but the sun which should be illuminating the scene is not. It shows up just fine in the preview render, but not the actual render. I’ve exhausted all my ideas on what could be causing it.
Here’s a shot of the city with lights and without the smog. Somewhere after this, I lost the word lighting.
So it appears the problem is once again with adaptive subdivision. If I have it enabled, I get no sunshine (from the world shader). If I turn it off, the lighting returns! Of course, the city looks like someone balled up some aluminum foil without the subdivisions… And another neat twist, if I enable static subdivision (rather than adaptive), Blender crashes.
So here’s a preview render (only 64 samples) with no subdivision:
Another preview and update.
I added vertex groups to the particle emitter, and created a second particle system. One system contains a single particle which renders the city block with an adaptive subdivision modifier. The other system contains 81 particles which render the block without any modifier. Doing it like this, the light from the world shader works as it is supposed to!
It also consumes far less memory, which I find concerning. As these are instances, and I’m now instancing two meshes rather than just one, I expected memory consumption to increase. Instead, it went from ~119GB with all 82 particles rendering the mesh with subdivision, to ~62GB with 81 of them rendering the mesh with no subdivision.
I’m happy to have overcome that hurdle, and can now continue to make progress. Here’s another preview:
Next up is to add more smoke plumes from the smokestacks, and adjust the building lights some more (a couple of problematic areas need fixing).
Any suggestions for improvement? Do you prefer the more expansive city with the very distant skyline, or the first image with the skyline much closer? Do you prefer the buildings with or without lights? Darker vs. lighter scene? Any other thoughts?
I decided to start a new scene and append/import the various pieces from the original. So far, so good.
Here’s an updated preview render with a focus on the smog (new smoke sim too).
I am working on similar scene… Please tell me - what about volumetric and shadows parameters? It is really hard to find enough good and economical values, especially for animation…
I’m using Cycles, and have the volume step rate set to 1.0 (the default). Since the smog is a smoke simulation, there isn’t any benefit to reducing it below the voxel size of the simulation.
Are you using Cycles or Eevee for your scene?
If you are looking for a uniform fog in your scene, then you should just use a cube with a single density value in its volume shader. That will consume the least RAM, and is very quick to compute.
If you want variation in your fog, you can either create it procedurally in the shader editor, use a volume object (with an external vdb or with the mesh to volume modifier), or a fluid simulation set to gas. The simulation and vdb options are more likely to use more RAM, particularly at high resolution. For speed of rendering, procedurally generated density has the potential to be slower if the math is very complex.
Are you running out of VRAM, or is it rendering slowly? If it is slow, you can increase your Render Properties->Volumetrics->Tile Size. This will speed it up, but in general won’t look as nice. You’ll need to try each size and see which gives you acceptable results and speed. The Start and End values within Volumetrics are also very important. Ideally, you want the range between them to just barely enclose the volumes in your scene. If it is set to .1m - 100m, and all your volumes are between 2-4m from the camera, then you won’t see all the detail you have available; you may even see visible ‘layers’ in the volume.
Do you have a link to a post for the scene you are working on? You’ll get better responses if we can see the problems you’re having.
Here are some links to some of my scenes which use volumes of different types: Pond in the forest and Leaf in a puddle use a simple cube with a uniform density (cycles). Sunburst and Soft Gradient use a cube with a density which is controlled by a gradient, more dense at the bottom, and less dense at the top. Cliffside pond uses procedurally created density variation (cycles). Nebula is a complex shader, and I had to keep the render size small so it would fit in VRAM (eevee).
The conversation on Eevee cloud test is probably the most useful for you.
I’ll likely rerun the smoke simulation. A few of the plumes are way too fat where they emerge from the smokestacks. I’m also going to try to add in a bit more turbulence or vorticity, and reduce the simulated noise to see if that makes more interesting plumes.
I’m not wild about losing the background city entirely either, so I’ll try to adjust things to bring it back into view.
