3
$\begingroup$

My ultimate goal: I’d like to create procedural cirrus clouds (long, thin, feathery high altitude clouds), ideally shaped fairly directly, e.g. with a curve. There are some very good procedural cloud systems for other types of clouds, but I have been unable to find a setup for realistic cirrus clouds. Part of the key to a realistic result is controlling the wispiness differentially along the “path” of the cloud, as these clouds tend to be puffier at their leading edge, then stretch out and become feathery along the trailing edge, with the feathery strands following the curve of the cloud, which follows air currents, presumably.

I’ve come up with a fairly realistic solution using geometry nodes and the volume cube node (see below), but it’s very slow, even for a single cloud, and my animation requires a dozen clouds or more. The key to making it work is that I’ve essentially created a custom coordinate system that follows the curve of the cloud to control textures differentially along the curve, in order to control wispiness as described in the first paragraph. I’m doing this in geometry nodes by using the spline factor to get the Z coordinate along the curve, and raycasting to extruded horizontal and vertical planes following the curve to get X and Y coordinates.

Geometry Nodes Cirrus Clouds Test

In theory, I could achieve a similar result more efficiently in shader nodes if I could create or access a similar custom coordinate system that follows the curve, but I can’t come up with a way of doing that in shaders nodes.

I can think of three theoretical solutions. Unfortunately, I can’t get any of them working.

  1. Use existing features of shader nodes to infer a similar coordinate system from a curve or mesh. As far as I can tell, the only texture coordinate system which follows the shape of a curve or mesh is UV, which doesn’t help with volumes.

  2. Use my current method of creating a custom coordinate system in geometry nodes, saving it in some way accessible within shader nodes and doing all the actual texture interpretations there. Unfortunately, geo nodes doesn’t seem to have a way to store any info other than density in a volume. It appears the roadmap for geometry nodes will eventually allow storing arbitrary attributes as new grids in the volume, but this hasn’t been implemented yet. Of course, named attributes are accessible within shader nodes, but they seem to only apply to a mesh surface, not a volume.

  3. Some other method of creating a volume that does allow custom data grids. Any ideas?

TIA for any suggestions!

-Tim Nolte Maskil Productions Ltd

$\endgroup$
4
  • $\begingroup$ Very interesting question! Have you ever looked at the EmberGen? $\endgroup$
    – quellenform
    Dec 29, 2022 at 0:41
  • $\begingroup$ You can view the timings for node by enabling the overlay, devtalk.blender.org/t/display-node-execution-time/21375. This will let you find any bottlenecks. I suspect the raycast nodes are the bottleneck, but without seeing the node tree I am really just guessing. If raycasting is the issue, you may be able to use different nodes to get the X and Y coordinates. $\endgroup$
    – Valalala
    Dec 29, 2022 at 5:57
  • $\begingroup$ Hi Quellenform, yes, I have Embergen. I’m not sure of a way to create arbitrary data grids in VDB exports from Embergen either, though I haven’t looked extensively. Of course, it may be that I could simulate the cloud formation entirely in Embergen, although that would be somewhat less deterministic than using textures in Blender. On the flip side, since feedback is realtime, it does allow quick iteration. I may experiment with that. $\endgroup$
    – Tim Nolte
    Dec 29, 2022 at 18:43
  • $\begingroup$ Thanks Valalala, I do have node timings turned on. They actually show as very short for the raycast nodes, but I suspect that’s misleading, and is only reflecting the time it takes to call it once. It’s the volume cube node that reports a very long compute time, but I suspect that's because to compute the field used as input for the density of the volume node, it must call the raycasts thousands of times. I’d love to come up with a more elegant solution than raycasting, but haven’t been able to yet. $\endgroup$
    – Tim Nolte
    Dec 29, 2022 at 18:44

0

You must log in to answer this question.