Mutable "In" ports in blocks

jfriedmanjfriedman Posts: 74 ✭✭

I'd like to talk about an aspect of blocks that took me an embarrassingly long time to get my head around: that a block's 'in' port values are mutable and that this is not a bug but a necessary part of doing anything with blocks.

An example I was working on:

An example from a built-in block preset - this is pulled by the daisy chained 'in' port which is modified by this block.

I kept getting confused by this and feeling like I was breaking the rules by doing this, since I've been trained to look at a graph and if I see a port with its icon on the left of the node it's an 'in' port, and that value can't be modified by the node. Given that these ports are really 'io' ports, I think I partially understand why this is like this. it's because inside the block, the "out" side of an 'io' port wouldn't make sense, so all ports are 'in' ports as far as the UI goes and 'io' ports as far as the compiler goes. Is that roughly correct?

This may seem like a silly thing to complain about but it's really making a mess of my mental model of the graph. Perhaps a better way would be- allow users to create both 'io' and 'in' ports on blocks. 'in' ports would be immutable inside the block as usual, and 'io' ports would be mutable but would not have the "out" side exposed inside the block. On the outside of the graph, these ports would be shown with the port name in the center of the node.

Anyway, my handle on all this is still tenuous so please set me straight if I have any of this wrong.


  • Roy NieterauRoy Nieterau Posts: 256 ✭✭✭

    This has fooled me just as much. For me personally it would make much more sense to understand that whatever happened in there will continue onwards and is identified as IO (mutable data). Because as you explained, it basically seems to work like that.

    Especially because I believe there could definitely be potential to have inputs that are immutable, like constants coming in, I think it's good to start differentiating. Having something as "in" identifies it towards the user that it's not meant to change inside the loop. It tells you, don't try and change it!

    So I believe I've been running up against a similar wall as you started with and I would also happily be set straight if I'm reading the Blocks wrong.

    In the above example of the preset is it possible the normals come out changed at the end of it? I wouldn't know.

  • jfriedmanjfriedman Posts: 74 ✭✭

    I think yes, it's totally possible for that graph in the screenshot to modify the normals, if you don't know anything about it's internals. This is the deformInPlace preset, btw.

    It doesn't expose modifying the normals to users by just passing single values to the user instead of the whole array. But the pictured graph, without checking the internals, is totally capable of modifying the normals just like the positions.

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

    I think yes, it's totally possible for that graph in the screenshot to modify the normals, if you don't know anything about it's internals. This is the deformInPlace preset, btw.

    Had a quick look but in this particular case it's not actually that easy to "break" it. In this case I was unable to have adjustments on the normal in the block to have effect outside of it. (e.g. see attached graph) The set() methods look like in-place adjustments but they don't propagate into the normals attributes, or am I missing something?

  • jfriedmanjfriedman Posts: 74 ✭✭

    It's not possible in the user-exposed part of the graph, because that passes in just a single Vec3, which is passed as a simple value, and modifying it makes no difference. If you pass in an array in a user-exposed port though, you can modify that using the execute port on your pass through node as you did though.

    If you want to make a for loop to modify an array, for example, and you just use the for loop preset, you'll have to do that kind of thing. The array.modify block preset once again hides that away by passing in only a single value at a time to the user-defined portion of the block.

Sign In or Register to comment.