Does Control Rig Blueprints have a limit to the execution count?

[lrpvot]

I’m finding in my control rig blueprint that I’m having to disconnect execute in the Backwards Solve, and as the rig gets more complex I’m having to peal back execution in the Forwards Solve. I’m finding if I can find optimization in my functions to execute less nodes overall that it helps reduce the amount of peal back that I have to do. Is there a way to increase the overall amount of execution?

[lrpvot]

Its seems to stop somewhere after 65000 in the execution stack. I’m generating control naming procedurally and have other procedural elements for a bird wing. I’m finding this limit to be too constrictive. I think I can simplify but not sure if I can simplify enough to accommodate backwards solve.

[lrpvot]

seems similar to this issue

Control Rig procedural element limit quiet failure

Hi all, forgive if posted in the wrong place or format, first time submitting to the forum. I’m running into a kind of silent failure state (no log messages to indicate any issues) where if I hook up any more blueprint nodes into my construction graph, the rig will start to “turn off” entire earlier segments of the construction graph when it compiles. It’s not particular to any node (I can hook up any subset of construction graph nodes in any order, and it only starts to shut off nodes once the…

[lrpvot]

I’m finding the pattern of using switch to control if the rig function builds Construct, Forward, and Backwards causes the execution stack to triple. If I create a function per Construct, Forward, and Backwards instead of all 3 living in one function (using the switch), I’m getting significantly less executions.

[lrpvot]

Just chiming in to say using switch node seems to cause the evaluation to double not triple. I’m hoping that breaking my functions into Construct, Forward and Backward solve will help reduce my execution stack. This instead of doing all 3 in one function using a switch.

[lrpvot]

Testing breaking the single function with switch node into multiple functions with no switch node seems to be working to reduce my execute stack by half. There is a bug there for sure in using switch nodes to switch node graphs between construct, forward and backward. I’m testing in 5.6 and haven’t tried 5.7. There’s things I like about the combined and split functions, would have been nice if the switch pattern was optimized though. Was reducing the amount of functions in my function library. However with the split function I’m now able to comfortably have backward solve again without reaching the arbitrary execute limit.

Anyone from Epic or with more experience please correct me or shed any light on this issue, regards.

[lrpvot]

(post deleted by author)