Itoo Software Forum
RailClone => RailClone Pro (*) => Topic started by: Adnan Malkoç on February 25, 2021, 04:11:18 PM
-
Hi!
I have a generic question about optimization which may be hard to answer in detail but I'll be glad if anybody shares overall information.
Does RC calculates every node in the editor whether it's used or not? If I keep many unused generators, arithmetic operators, segments etc. in the editor, does it make any difference in performance. If so, which nodes affects which part (memory usage, rendering speed, loading times etc.)?
Is there any tips and tricks page about performance like "if you do x instead of y, it's faster" or "x always consumes more memory than y".
Thanks
-
Hi,
No, unused and disabled nodes don't take part in the graph evaluation.
The performance hit should be minimal, because they are take in account only when style is editor or 'compiled' (which is a minimal part of the process).
I will try to describe the main stages of the build process:
1) Style is 'compiled', converting it from text (a XML) to a set of objects in memory (one by node).
2) Splines, surfaces and other scene objects are prepared.
3) Each one of the Generators is processed over the spline, evaluating their dependent nodes in sequence (from the generator to the segment), and generating a set of pre-processed segments.
4) These pre-processed segments are joined and converted to the final geometry. Those which can stay as instances are sent directly to the render engine.
Most of the process time takes in step 3,4. And unused nodes are skipped on these stages, so their impact is minimal.
There are not nodes with more performance hit than others. The only exception would be the Arithmetic expressions, but with a marginal difference.
But there is a large difference regarding memory and performance on stage 4, depending if RailClone must generate a set of instances for the render engine (fast), or a whole mesh for the viewport (slow).
I hope that helps. If you have any doubt, please don't hesitate to ask.
-
I'm glad with your nice and detailed explanation. Thank you for your time.
Your explanation mostly focused on render part as much as I understand. So "building" is the hardest time.
What about working in the editor or viewport.
No, unused and disabled nodes don't take part in the graph evaluation.
If there are many unused nodes in the style editor, does it also affects performance during changing/modifying parameters or only during last build?
Now I'm experiencing slow downs because of my "garbage" style. Because of some neccessities I had to keep many different generator setups in a single style.
Also depends on my needs, I manually choose and connect them to final generators. It's a manual selector garbage...
I've asked this question because you may say "Don't clutter your style with unused things, separate them into different RC objects" or something like this.
But there is a large difference regarding memory and performance on stage 4, depending if RailClone must generate a set of instances for the render engine (fast), or a whole mesh for the viewport (slow).
Does this mean even things gets slow down during viewport display, they will be fine before rendering? Is it related with display settings like mesh, pointcloud etc?
One more extra question. Is randomised UVW mapping(offsetting), ruins instancing?
Sorry for bothering you again.
Thanks in advance.
-
I will share my experience:
1. Style editor load time is the slower the more items in it. used or orphaned.
Make use of "Select Children" selection and move selection. Clean stationary items.
(https://i.imgur.com/yuroUZh.png)
2. Build times are fastest with BOXES display mode.
3. Rendering consumes more RAM if You have deforming objects (each segment that is not instanced requires its RAM, so the more complex the object the more ram is required)
4. More about instancing (https://docs.itoosoft.com/railclone/requirements) in our documentation.
Feel free to do Your performance tests with RailClone Stats utility:
(https://i.imgur.com/wlZzEiw.png)
One Note from Carlos:
Macros have no difference regarding performance (positive or negative).
They are expanded on the style compiling process, to create a unique full graph.
-
Your explanation mostly focused on render part as much as I understand. So "building" is the hardest time.
What about working in the editor or viewport.
Well, that's a different matter. Although unused nodes don't participate in the building process, they must be handled by the Style Editor when graph is modified.
I'm not sure about the performance hit, because when user interaction is involved, it's most difficult to measure it.
If there are many unused nodes in the style editor, does it also affects performance during changing/modifying parameters or only during last build?
Unused nodes should have an impact only on stages 1,2 which are less costly. Anyway, we cannot understimate them, specially if there are tons of them.
You can test it using the Statistic window, removing unused nodes to see the difference. This is the correlation of each section with the build stages:
'Style Evaluation': stage 1
'Splines Setup' + 'Seg.Transform' + 'Geometry Setup': stage 2
'Generators': stages 3,4
'Mesh creation': stage 4
Take in account that each time you modify a parameter, or modify the style in the editor, RC triggers a rebuild event (all stages are processed).
Does this mean even things gets slow down during viewport display, they will be fine before rendering? Is it related with display settings like mesh, pointcloud etc?
Yes. 'Mesh' display mode is the most costly configuration. Segments cannot be instanced, and RC must build a whole mesh with the full geometry.
The more optimal modes for viewport are Box, Point-cloud, and Quick mesh (in this order).
One more extra question. Is randomised UVW mapping(offsetting), ruins instancing?
It depends of the render engine. V-Ray (not GPU) can apply the UVW mapping at render time and keep instancing.
This is not possible with the other engines, because we have not way to write a mapping render shader (there is not a render SDK, or this feature is not supported)
-
Hey there!
Thank you for the explanation again. Thank you Rokas and Carlos! I really appreciate your helps.
I believe I got my answers and many people will use this information as well. Thanks!
Now it's time to play hide and seek with the nodes...
Adnan
-
While I was experimenting I noticed something. Let's say, my style working with 200ms normally. I can extend my path really long, add some markers and change geometry along the way. All is ok until I use some null segment with marker. When I change marker ID to use null segment, build time climbs up to thousands of milliseconds (seconds? :D). Array of full geometry 200ms, array of nothing 10.000ms!
This delay also depends on the quantity of null segments. Actually I was expecting the exact opposite. What's wrong with this?
-
Please share the file
-
Oh! After testing and testing I found out all this delay caused by transform node position. I mean, there was a single transform node at the end, between final selector and generator. It was only adding L/R padding. When I moved this node "before selector" building time became 60ms. That's really weird. Result is exactly same but calculation times was disaster.
Is there any explanation for this so I can stay away this kind of... things?
Thanks!
-
Don't limit Your creativity by those ms.
-
:D :D :D
No, I don't! But when it reach to 10000ms, IT limits me.
-
:D :D :D
No, I don't! But when it reach to 10000ms, IT limits me.
if You had attached the scene we could debug it.
-
Oh, thank you. I'll do but first I have to arrange my messed up style. Now it's a bug already... :'(