A Bird's Nest

@dfelinto sked me to have a go at seeing what kind of solution I could come up with for creating a procedural birds nest using the curve nodes as a bit of a litmus test.

The initial nest created by @JulienKaspar comes from the Sprite Fright production file:

This example was created manually which does create a lot of opportunity for creative direction but is also very time consuming. The result we see has a solid base mesh to fill in the gaps, presumably to save an artist adding hundreds of manual curve objects.

My approach was to create a curve object and instance it around a procedurally generated nest form. This would create a bit of a mold that defines the shape and then still allows for arbitrarily dense layering of the curves while maintaining visual consistency.

In a real production setting the initial curve object could (should) be made manually and the nest form as well could be created manually for speed and creative direction.

Creating The Nest Form

The profile curve is simply a circle with the top pulled down and then swept around a semi-circle with a very small radius. This is something that would be easier and faster by hand but done with nodes as a test.
Attributes made this slightly more cumbersome than needs be but the logic was fine. Rather than manually creating a semi circle, a spiral node could have been used:

Instancing Curves

Instancing the base curve object onto the nest form was very simple but from a useability point of view we really need to be able to instance curves and geometry directly without needing to create additional objects.

You will find in the file that simply trying to move the objects being instanced is incredibly laggy even though their object transforms are immaterial to the calculations.

Twig Shapes

Using an attribute randomise on the position of a curve lets you randomise the control points which is great because you don’t end up kinking the edge like you would with a mesh object. In this case a curve subdivide node is used as well to increase the number of control points.

To make these look more twiggy I also randomised the radius. Something that would have been real beneficial here would be more interpolation types. There’s a lot of use cases for having more falloff / interpolation types but even just with this, short of using a Curve Map node, I had very little control over the variations in radius. When we look at the Map Range node in Animation Nodes we see a lot more options.

Even if these weren’t directly added to the node, having a socket that allows you to plug in different interpolation types from a dedicated node would make sense here.

There also really wants to be more selection methods. Selecting by Region as well as Selection by Index. Once these curves were made real there was no way to differentiate between them. Attribute Transfer only works by proximity rather than inheriting attributes from point to instance. Even an object index would be a big benefit. This way you could do something like mask between random curves and make some into feathers and some into twigs, or different kinds of twigs etc.

The base tools on actually generating stuff is good, there’s a solid foundation. Artists still can’t easily manipulate that data though so I’d want to see more data being exposed.

The fields workflow would certainly be more streamlined and artist friendly but still doesn’t quite solve the basic need for more analysis to create data about objects or selecting individual objects out of a set. Generating ~250 curves for this nest but from a user POV, they’re just treated as 1.

Feel free to dive into the file: ErindaleNestTest.blend - Google Drive


Nice work !

If we are speaking about interpolation, i’d like to point out this important weakness that could greatly improve the mograph community


Animatable falloff types would be great! The examples in your post could be easily solved by just animating the input values before the graph so a better use would be animating between entirely different shapes


And are you sure that a new type for this is necessary?
what if it’s a vector field? or curve geometry?

just thinking out loud. a falloff is only but a curve data or few positions afterall
new type mean no compatibility with all existing nodes. might be best to go for flexibility.

Have you seen this node? D12035: Geometry Nodes: Add Easing Function Node

For custom graphs, it would nice to be able to sample regular curve geometry as if it was a graph, instead of (or in addition to) using the curve from the special widget.

This sort of thing is trivial with fields. Selection inside of arbitrary volumes is also possible with this level set patch. Maybe it would be nice to provide builtin node groups for some selection methods.


Can confirm, I just created a bounding box selection that supports rotation in the fields branch:


With a box sure (nice btw!), but with arbitrary geometry ?

Yeah, I guess we need a specific node for that.

1 Like

Would also be cool on a dedicated node to be able to support a toggle between total and partial selection

What do you mean with total and partial selection?

Something like this where we can choose whether something needs to been entirely inside the selection area or just partially.


Oh, yes! Indeed, that would be great!

@Hadriscus check this, if it’s the case let’s continue on that thread, I don’t want to hijack @Erindale 's topic.