Possibility of evaluating-by-Pull on DFGBinding

StephenTStephenT Fabric for MotionBuilder Posts: 78


I'm curious - is there any chance of making a binding only evaluate a given port, similar to the way Blocks behave?

For example, if I embed a graph in my application, that has 3 output ports, "LowRes", "HiRes" "Med" etc. I only need the results of one of these outputs at any given time.

Would it be possible to evaluate a graph based on a port "Pull", rather than via the "Evaluate" method?

I realize this is highly speculative, I'm also trying to figure out if I can get the same effect by wrapping my graph in a block (which has other benefits, for example a fixed input/output schema) but this runs into other problems - namely, that I can't directly pull the block ports, and that I can't limit the DFG editor to just the contents of the block.

Anywho, let me know what you think


  • malbrechtmalbrecht Fabric for Houdini Posts: 755 ✭✭✭

    Moin, Stephen,

    my initial idea would be to use a cache node on each "thread" so that parts left of the cache only get reevaluated when necessary.


    Marc Albrecht - marc-albrecht.de - does things.

  • HelgeHelge Moderator, Fabric Employee Posts: 315 Fabric Employee

    Hey @StephenT,

    the graph is not using a pull model as you envision it. Basically if you set an argument on the left side of the graph it will dirty all of the nodes affects by it. The evaluate method then computes all of the nodes required - after which you can get the resulting arguments on the right.

    The evaluation methods used within the DFGBinding have been chosen to allow compilation of the full code within the binding. To perform pull based evaluation is possible of course - but it's a rather large undertaking.

    As Marc suggests - you can implement basic functionality like this by using cache nodes.



    Research Engineer @ Fabric Software

  • StephenTStephenT Fabric for MotionBuilder Posts: 78

    Thanks to you both. I think you're right malbrecht - using a combination of cache's and semi-intelligent design I can get what I need.

    @Helge I figured the graph's have a dirty model - thats how the DCC integrations are structured - but in tests I've been able to control evaluation path by using (for example) "if" nodes. The "true" path of the "if" node will be evaluated, while the false is not, which (if not necessarily the same as) kinda feels like a pull model. Also, I've designed my blocks areound the 'pull' paradigm. For example, I have a manipulation block which exposes a variety of ports - "mousePress", "mouseMove", "doubleClick" etc. Only the port being pulled is executed, allowing me to create quite a natural, DFG-only implementation of my mouse tools.

    Am I relying on an internal implementation feature that I shouldn't? I understand (and never really expected) DFGBinding to change the way it behaved, but should I be more careful about the evaluation expectations within a graph?

  • HelgeHelge Moderator, Fabric Employee Posts: 315 Fabric Employee


    You should be fine using them as you are right now. In fact that is an interesting use case :smile:

    Research Engineer @ Fabric Software

Sign In or Register to comment.