Allen Lee

edward
Some of this is very much in progress as we indeed are building higher-level components for the next major release.
- I'm not sure about your node named "%tag()" issue. I suspect it might due to using %tag() in a place that only expects a name, not a pattern.
- When the graph becomes too complex, APEX Script is the way we envision things going. This allows one to scale up to production rigs.

There are starting to be some tutorials in the mean that you can check out if you haven't already. Go to https://www.sidefx.com/tutorials/ [www.sidefx.com] and type in "apex" as the search term. For example, someone made an APEX Script tutorial:
- https://www.sidefx.com/tutorials/effective-apex-scripting/ [www.sidefx.com]

Thank you for your reply. I'm looking forward to the next version. I've gone through many tutorials, and although it's still challenging, things are gradually improving. I encountered some issues while creating rigs with build-in components, so I had to dive into the nodes to check and understand the logic within. It's a painful yet joyful experience.~XD,THX~

Recently, I’ve been looking into some built-in component graphs and wondering if my current understanding is roughly correct.

I hope to establish a relatively clear approach to learning how to build graph workflows.
While the process can be optimized and modified, having a baseline to start with is essential.

When the graph becomes too complex, it’s easy to lose focus or overlook critical operations.
Its flexibility makes it feel like some level of structure or constraint is needed to help with understanding and getting started.

It's great to get some advice about apexgraph work flow ,THX~~

some more question:
autorigcomponent -> transformdriver:
we use tag-pattern-func in the driven parm, component will add a joint named with this tag,e.g:'%tag(Pelvis)',and parent this new joint ,why not parent the true taget joint in orig skel? What are the benefits?