Simulations and Blocks (Variables?)

Roy NieterauRoy Nieterau Posts: 258 ✭✭✭

Hey guys,

I wanted to check what the preferred method would be to start doing simulations with Blocks. For example a simple "jiggle" on a mesh. This would require to remember velocities and previous point positions, as such I was thinking variables.

Manipulating such variables within a block seems to be rather complex since they reinitialize each time when declared there. So one would have to produce them outside of it, get the indices from the arrays inside of it and then get the array out of the block again and set them.

I've been playing around with it a bit and somehow the methods I tried felt convoluted and odd. Attached is such a quick test setup. So I'm guessing this can be done a lot easier, and was wondering what other workflows are possible? Or even what would be recommended?


  • mootzoidmootzoid Fabric Employee Posts: 185 Fabric Employee

    Hi Roy,

    I think the best approach would be to define the variable inside the block preset, i.e inside the node and not inside the block.

    Attached is a graph that demonstrates the above.
    Enter the "ModifyInPlace_1" node (the node, not the block's body) and you will see the variable. If you then enter the ForLoop node you will see how the value is passed to the block.

    Let me know if this helps!


  • Roy NieterauRoy Nieterau Posts: 258 ✭✭✭
    edited September 2016

    Thanks, that does make more sense!

    Nevertheless still some questions arise:

    • The drawing of previous positions does feel odd though. How does it know (in your version) that it should trigger that drawing part of the graph before the one entering the block (so the order of those two get.prev nodes). Because it seems to be changing the variable in place. (Since there are no set.variable nodes) so if it would run after the block it would be wrong (drawing the current points instead)
    • How come the "exec" port of a subgraph isn't triggered by default if anything of that subgraph is pulled. (Somehow I imagined it would?) Currently I'd need to connect the exec ports on a subgraph outside of it for it actually function.
    • Why is there no exec port inside a Block? Currently I have been forcing a pull by connecting it to the exec plug on the PassThrough node. Is there a particular reason this does not exist within a Block graph?

    I played around with it a bit and have a fairly simple jiggling frog now. Attached the most amazing artwork ever, hehe!

    Also note that I threw off the drawing handle attribute coming out from the deform node, and just hooked it up internally to it. Seems there's no need to connect it to the outer graph. Also know visually it makes more sense to me when it's being drawn. Is this actually the "wrong" way to do it? (Or should I apply the if it ain't broke don't try to fix it rule here.)

  • mootzoidmootzoid Fabric Employee Posts: 185 Fabric Employee

    I like that jiggle effect, very cool :)

    • in my example the order of execution is defined by the order in which I connected the ports to the exec port. Not the best way, I admit, in fact I should have used an Execute.Merge preset or simply expose the ports so that one can actually see the order in which they are executed, see image.
    • the exec ports are somewhat special. They let you execute parts inside of a node before the actual node is executed. See the documentation on Execute Ports for more details port
    • we removed the exec port inside a block by default because it was not obvious whether the KL command dfgPullBlockPort that pulls a port would also pull the exec port or not.

    Hope this makes sense.

    bak.jpg 37.4K
Sign In or Register to comment.