Transform vs Randomize/Selector

[Dragan]

Just a quick question to avoid testing on a large scale.

eg. I have a segment that has to be rotated by 90deg through various nested generators.
What will be the faster/efficient way to do it regarding RC programming code (how it works under the hood):
- use Transform_rotate>Random Calculated on Segments for the original segment or
- use pre-prepared segments (original and rotated ones) and go via Randomize / Selector>Random on Segments Operator

Sometimes I can solve some difficult tasks with some smart Expressions and just Transform Nodes that look elegant and nite in the Style editor but maybe it is not build-time efficient than the approach in some other more complex way in the Style.
The bottom line is whether there is any preference for using Transform_rotate>Random on Segments VS Prepared segment>Randomize/Selector?
I`m just interested in the build time

Tnx.

[Paul Roberts]

That's an interesting question. I've just used the basic scene attached to do a quick test and overall the expression won



Digging into the detailed stats though, the generator build time is actually slightly longer for the expressions at 5ms vs the geometry version at 3ms. The bulk of the time difference is due to the Geometry Setup phase



Hope that helps,
Paul

[Dragan]

Hm, I'm surprised that the geometry setup is so long. Is this related to geometry polycount, segments count, or something else?
This will be quite a value looking on a large+nested scale. We should dig more about this.
Thank you

[Paul Roberts]

In my tests. geometry setup doesn't really increase with the number of instances so the difference is really quite negligible. For example, creating 10100 instances (instead of 625 as in the previous example) only added a millisecond or two in both versions.

Best,
Paul

[Dragan]

I was referring on number of Input Segments.
Is 4 x 90degSegments vs 1 x Segment_for_transforming has more impact on geometry setup?
Let's continue the testing with forced instancing workflow so we can exclude slicing as probably biggest impact on build and find out more about...

[Paul Roberts]

That's exactly it - geometry Setup involves preparing the meshes for use in RailClone, the more meshes used as inputs, the more costly this phase. My test had slice and bend disabled. If enabled, this affects the segment transform statistic.

Cheers,
Paul

[Dragan]

In that case, my next point of interest will go to the Segment Inputs.
I will test it myself but you will probably do it more thoroughly because you are on the source.  (so not happy not living in Cádiz already  )

eg. Windows:
I`ll do Selector for Hinges & Null Segments Input at the start of the graph to select whether the hinges will be displayed or not. Since this selector will be in Nested Generators does this mean it will be included in the calculation even if Null Segment is selected at the start? I guess it will. So in that case it may be better to go with hinges as a separate Generator workflow witch just can be turned on/off.

Cheers,
Dragan

EDIT:
- Well... tested and seems to be working as expected. When the Null Segment is at the start there is no further evaluation since there is no geometry. I was afraid for the nested generators it will evaluate backward (similar to how transforms are working) and evaluate everything until the point RC realizes there is no geometry at the start.
So, this is good.

btw. Statistics is not refreshing automatically after the changes in the style. It will be nice to have some kind of auto-refreshing mode for the type of testing we are doing at the moment.