Search - User list
Full Version: Directly Editing Graphs non-destructively in APEX
Root » Technical Discussion » Directly Editing Graphs non-destructively in APEX
evanrudefx
Hello,

What is the best way to edit the Base.rig graph directly, but also non-destructively? If I have a autorig component, I can plug an apex graph node into the auto rig component's second input, the set the component source to "use second input". From there, I can procedurally use the extract character graph/update character graph to make changes to the Base.rig graph. This is great for procedural edits, but a very tedious way to work. I want to directly edit the Base.rig since my rig is fairly small and it's faster to work that way (in this scenario).

The direct way of editing the Base.rig graph is to use unpack folder, unpack the Base.rig and use that as the input to a apex graph node. The issue is that the apex graph node stashes the input, so it feels like it is destructive. If I make any changes before the graph sop the only option (I see)to fetch the new results is to hit reset, which loses my edits. Is there a better way to directly edit the Base.rig graph without stashing the input graph, or is that not possible?

Thanks
raincole
Edit Graph has to stash the input. I don't think it even stores 'diff'.

To diff two arbitrary graphs is actually a very difficult problem to solve in computer science. One simple implementation might be just assuming that the nodes with the same id are the same one, like how Houdini usually treats meshes. That would handle some very limited scenarios. But I don't think Edit Graph has this feature, so unless SideFX decides to add that you'll have to write your own diff algorithm...

If your edit is rather trivial, I think LLM should be able to translate the edit into an APEX script for you so you can just go the procedural route. I haven't tried that though.
evanrudefx
raincole
Edit Graph has to stash the input. I don't think it even stores 'diff'.

To diff two arbitrary graphs is actually a very difficult problem to solve in computer science. One simple implementation might be just assuming that the nodes with the same id are the same one, like how Houdini usually treats meshes. That would handle some very limited scenarios. But I don't think Edit Graph has this feature, so unless SideFX decides to add that you'll have to write your own diff algorithm...

If your edit is rather trivial, I think LLM should be able to translate the edit into an APEX script for you so you can just go the procedural route. I haven't tried that though.

Thanks. I don't understand the technical aspects of how they work, just trying to see if there is a better/faster way to work. It takes a lot of effort to perform basic tasks when going the component script route. For example, to multiply three floats,the simple task of connecting 3 float nodes into a multiply node becomes multiple graph add nodes, find ports, graph connect inputs, etc. After performing a few simple tasks I have already an insanely large network, I was just wondering if there was a better way to directly edit the graph because it can be way faster to prototype/test things or even build all the rig logic that method.
esttri
You can use the fuse graph workflow this is designed exactly for that. It allows manual graphs edits that then get procedurally fused into the main rig graph.

Go to the Fuse Graph Section in this Tutorial section here:

https://www.sidefx.com/tutorials/intro-to-rig-builder/ [www.sidefx.com]

And here is also a walk through from the docs:

https://www.sidefx.com/docs/houdini/character/kinefx/customrigs.html [www.sidefx.com]
evanrudefx
esttri
You can use the fuse graph workflow this is designed exactly for that. It allows manual graphs edits that then get procedurally fused into the main rig graph.

Go to the Fuse Graph Section in this Tutorial section here:

https://www.sidefx.com/tutorials/intro-to-rig-builder/ [www.sidefx.com]

And here is also a walk through from the docs:

https://www.sidefx.com/docs/houdini/character/kinefx/customrigs.html [www.sidefx.com]

Thanks, this is exactly what I was missing. BTW great presentation for h22! all the new APEX stuff looks amazing.
evanrudefx
esttri
You can use the fuse graph workflow this is designed exactly for that. It allows manual graphs edits that then get procedurally fused into the main rig graph.

I took a look at it. I don't think this avoids the issue I was referring to. The issue I had was the apex graph node stashes the input graph, so it doesn't get any changes made to the incoming graph. The docs say this about the input on the apex graph sop:

"The APEX graph geometry used as the initial graph to edit. After the graph is edited, the input is ignored. This input can also be a packed folder structure."

The incoming Base.rig graph is still stashed in apex graph sop, so if I make changes before the apex graph sop (like adding a new joint), they do not propagate into the apex graph sop. I have to reset the graph to fetch new updates, which then results in losing everything I did in the apex graph node.
esttri
You need to give all the nodes you do not want to modify a tag called REFERENCE in the graph SOP. You can even delete them and it would still work. That way only you modifications get merged in and the upstream updates of your input graph properly show up..it also make the fuse step a loooot faster if you do that.

In other words we really only care on the edit graph SOP about the stuff you want to merge in not the rest. The rest is completely ignored, so it's not important if it's up do date or not of if you delete because it's not going to be used for the fuse process. And only the fuse process on the auto rig component node is the step that then takes the updated rig into account so you need to look there, not at the edit grap for the procedural update behavior!
evanrudefx
esttri
You need to give all the nodes you do not want to modify a tag called REFERENCE in the graph SOP. You can even delete them and it would still work. That way only you modifications get merged in and the upstream updates of your input graph properly show up..it also make the fuse step a loooot faster if you do that.

In other words we really only care on the edit graph SOP about the stuff you want to merge in not the rest. The rest is completely ignored, so it's not important if it's up do date or not of if you delete because it's not going to be used for the fuse process. And only the fuse process on the auto rig component node is the step that then takes the updated rig into account so you need to look there, not at the edit grap for the procedural update behavior!


Thanks, I really appreciate the replies. What you are saying makes perfect sense (and I previously didn't know that), but I feel like it does not address the original issue I was talking about. I will try to rephrase it.

1. Using component script (apex graph into second input of auto rig component) isn't an ideal way to work for every scenario (like fast prototyping or working on a small rig). If I need to multiply three vectors and wire the product into the rot of a transform object, it becomes the tedious task of graph add node, graph add node, graph add node, graph add node, find port, find port, find port, connect input, connect input, etc.

2. Apex graph allows me to directly edit the graph so I can work quickly. But this comes with the cost of stashing the graph. Example, I connect a vector into the rot of my two transform objects (that are my two joints). I decide to add a third joint and want to connect that vector into the rot like the other two. That third joint won't show in the apex graph sop because the initial graph that is stashed only had 2 joints. I can reset to fetch the new joint, but then I lose my work.

My question was whether or not there was a way to directly edit the graph like using the apex graph sop, but still be able to fetch changes to my original rig (like adding a joint).

What I have gathered is there isn't a way to do this. I should either use the component script method, or use the fuse graph method like you suggested (only care about stuff that is being merged).

Is that assessment correct?

Thanks
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB