3
$\begingroup$

I’ve created a complex road system in Blender using Geometry Nodes. The system is based on a curve, and I extrude profiles and scatter objects along that curve. The setup has about 180 individual sockets, which is starting to feel overwhelming in a single Geometry Nodes modifier.

To make it more manageable, I want to split the system into multiple Geometry Nodes modifiers stacked on top of each other. For example, one modifier for foliage, one for road signs, and so on.

To achieve this, I’m using the Separate Components node in each modifier after the first one. This allows me to reuse the same base curve for scattering instances in each modifier. At the end of each modifier’s node tree, I combine the previous geometry (instances and meshes) with the curve using a 'Join Geometry' node. This way, I can keep using the Separate Components node in the next modifier.

My questions are:

  1. Is this approach bad for the performance of the system?
  2. When I use the Join Geometry node on instances, will it combine them in a way that adds unnecessary calculations or bloats the indices?

The .blend file

Setup and Geometry Nodes modifier 1

Geometry Nodes Modifier 2

Geometry Nodes Modifier 3

Improve this question
$\endgroup$
4
  • 3
    $\begingroup$ In principle, it depends very much on the geometry and, above all, on the individual attributes that a geometry contains. For example, if you define ten individual attributes in a geometry, these ten attributes will also be created in the geometry that you join additionally. Even if they are not given values, it can still significantly affect memory requirements and performance. $\endgroup$ Commented Jan 29 at 11:19
  • $\begingroup$ @quellenform Thanks for your explanation. I tried the method described by Gordon Brinkmann below and the total timings seem to be the same for the two situations (one modifier VS two modifiers). It's about 19ms in both cases. I'm not sure why this is, but I think that's a good thing? $\endgroup$ Commented Jan 31 at 13:45
  • $\begingroup$ Now that you are only creating geometry in two different node trees in your specific case, which you would have created in one anyway, I am not surprised that the calculation time has not changed dramatically. And since you are specifically separating two different object types here, whose attributes cannot be mixed (Curve, Mesh), the concerns I mentioned in the previous comment are no longer relevant. The attributes are therefore only ever added within a domain if they are not present in the joined geometry, and that is precisely what could affect performance under certain circumstances. $\endgroup$ Commented Jan 31 at 14:00
  • $\begingroup$ @quellenform Thanks for that clarification! That's good to know. $\endgroup$ Commented Jan 31 at 16:46

1 Answer 1

Reset to default
6
$\begingroup$

Without checking your specific nodetree and just saying "yes, it affects the performance" or "no, it does not" or "not much", instead I give a more general answer how you can try to check it for yourself also on future nodetrees:

There is an option Timings in the Node Editor Overlays. When you enable it, each node has its computing time in miliseconds above it and the Group Output shows the cumulated time overall for the node setup. Change nodes and find out how it changes the resulting time in the Group Output.

gn timings

If you use several modifiers they are calculated in order, i.e. the second modifier needs the result of the first modifier to build upon, so I would assume the timings add up and the time it takes to compute both modifiers is (at least) their separate timings added together.

So you can check the sum of times per modifier and compare it to having all in one modifier.

For your question if it "bloats the indices": Each modifier starts with his own set of indices, starting at 0 (per element category), if that is what you are asking. The indices of a second modifier are not continued from where you left in the first modifier.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Hello Gordon, Thank you very much for your clear explanation! This is very useful to know. When I test everything under the same conditions—comparing the combined timings of two modifiers with the timing of a single modifier—the results seem almost identical: 19 ms. So at first glance, it looks like there is hardly any difference. Thanks again! Is there a way I can treat you on a digital coffee? :-) $\endgroup$ Commented Jan 31 at 13:40
  • $\begingroup$ @PieterLéon Glad I could help. But don't worry - I got a lot of coffee here and accepting answers if they help you is our "currency" here, so everything's fine :) $\endgroup$ Commented Jan 31 at 13:49
  • $\begingroup$ Hahah, well thank you very much. That's very generous! $\endgroup$ Commented Jan 31 at 13:52

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.