Module Index Internal Parameter
Module Index Internal Parameter
What do you think of having an 'Internals' feature that provides the Index of a module based on the position of its output noodle into the next module or its input noodle from the previous module.
Simple use case: a (say polygon) module is connected to 10 transform modules each of which could use its index to position itself automatically.
Extended use case: use the Index in the expression modifier for a wide range of effects.
In addition to these simple use cases, this would open up the possibility for the following...
A single module could be virtually instanced, adding input and/or output connectors as required e.g allow a single transform to have 10 inputs and 10 outputs each, where the input and output indexes are available to the parameters and modifiers are applied to each instance. In the mock-up image above, the first input would be scaled on X to 0.1 and sent to the first output, the second 0.2 and so on, thereby having 10 images progressively stretching in the X dimension. Could be used like an Array module but much more powerful.
One could also imagine chaining these instance modules together e.g. 10 into 10 or 10 in 5 and another 5. Many possibilities.
Simple use case: a (say polygon) module is connected to 10 transform modules each of which could use its index to position itself automatically.
Extended use case: use the Index in the expression modifier for a wide range of effects.
In addition to these simple use cases, this would open up the possibility for the following...
A single module could be virtually instanced, adding input and/or output connectors as required e.g allow a single transform to have 10 inputs and 10 outputs each, where the input and output indexes are available to the parameters and modifiers are applied to each instance. In the mock-up image above, the first input would be scaled on X to 0.1 and sent to the first output, the second 0.2 and so on, thereby having 10 images progressively stretching in the X dimension. Could be used like an Array module but much more powerful.
One could also imagine chaining these instance modules together e.g. 10 into 10 or 10 in 5 and another 5. Many possibilities.
Re: Module Index Internal Parameter
What an excellent idea!
Re: Module Index Internal Parameter
Yes, a very good idea, thanks
.
![Wink ;)](./images/smilies/icon_e_wink.gif)
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Module Index Internal Parameter
This looks very useful
The instance count need not be explicit and a "Multi-instance" checkbox would be sufficient. Outputs could be added to match the actual number of input noodles, which would nicely match the way in which input pins are added.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
The instance count need not be explicit and a "Multi-instance" checkbox would be sufficient. Outputs could be added to match the actual number of input noodles, which would nicely match the way in which input pins are added.
Re: Module Index Internal Parameter
Imagine a single polygon piped into a translate and then output to an input selector. If there was only a check-box to declare the translate multi-instance there would be no way for it to know how many instances were required. If, however, the translate grew a few input nodules, the single polygon could be attached to each.
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Module Index Internal Parameter
Ah yes! I hadn't fully appreciated the versatility of your idea.
However, perhaps my proposal could still work:
Suppose that, when "Multi-instance" was checked, the output pin count behaved equivalently to the input pin count. An additional output pin is added as soon as one adds a noodle to an existing output pin. The actual number of active instances could be shown adjacent to the checkbox, to save counting them when very many are used.
EDIT: I feel I'm still missing something here![Confused :?](./images/smilies/icon_e_confused.gif)
![Embarrassed :oops:](./images/smilies/icon_redface.gif)
However, perhaps my proposal could still work:
Suppose that, when "Multi-instance" was checked, the output pin count behaved equivalently to the input pin count. An additional output pin is added as soon as one adds a noodle to an existing output pin. The actual number of active instances could be shown adjacent to the checkbox, to save counting them when very many are used.
EDIT: I feel I'm still missing something here
![Confused :?](./images/smilies/icon_e_confused.gif)
Re: Module Index Internal Parameter
If Eric chooses to implement the index internal parameter, that's relatively straightforward I think. If Eric chooses to implement the instancing, I trust that he will choose the most powerful, functional way to do it without breaking the UI/UX.
For the sake of discussion, picture this: an arguably not very functional but somewhat illustrative edge case is to have a single module connected to the Magic module. There would be no input pins and only one output pin. If the module had one additional unconnected pin, this could be connected to create additional instances. Each time an additional output pin was connected, a new unconnected pin would be made available. Modules already do this for input pins. Is this what you're missing Terry?
This brings up another potential feature that might be more necessary/logical with instancing but more disruptive to the current application. Right now, if a module is split into a number of paths, the same frame from that module is copied to each path. There is no way, for example, to send a 3 then 4 then 5 sided polygon from a single module - you need three polygon modules each with different parameters. Having the Index respected in an instanced module would allow each instance to be different using the Index but you'd also want to respect different random seeds, for example, and other ways to differentiate instances somehow.
The
is in the detail and I respect that Eric has these and many other details to contend with when considering new features.
For the sake of discussion, picture this: an arguably not very functional but somewhat illustrative edge case is to have a single module connected to the Magic module. There would be no input pins and only one output pin. If the module had one additional unconnected pin, this could be connected to create additional instances. Each time an additional output pin was connected, a new unconnected pin would be made available. Modules already do this for input pins. Is this what you're missing Terry?
This brings up another potential feature that might be more necessary/logical with instancing but more disruptive to the current application. Right now, if a module is split into a number of paths, the same frame from that module is copied to each path. There is no way, for example, to send a 3 then 4 then 5 sided polygon from a single module - you need three polygon modules each with different parameters. Having the Index respected in an instanced module would allow each instance to be different using the Index but you'd also want to respect different random seeds, for example, and other ways to differentiate instances somehow.
The
![Evil or Very Mad :evil:](./images/smilies/icon_evil.gif)
-
- Posts: 176
- Joined: Tue Aug 26, 2014 11:22 am
Re: Module Index Internal Parameter
a great idea !
Re: Module Index Internal Parameter
Yes, just the Index parameter by itself will be fairly simple. Anything beyond that will require more careful consideration.
-
- Posts: 711
- Joined: Sun Sep 14, 2014 8:15 am
- Location: UK
- Contact:
Re: Module Index Internal Parameter
@Eric I'd given this matter some consideration offline so I'm adding these thoughts belatedly in case they can contribute. Sadler may wish to differ, but here's my penny's worth:
- Multi-instancing could be enabled by a module menu option, regardless of how the instance count is determined.
- When multi-instance is enabled the module could have brackets after the module name, perhaps including the input and output pin counts eg Scale [5:5] or Translate [1:8]. Neatly, this would appear on the module's title bar from which the option had been enabled.
- I think Sadler and I envisage that the output pins would behave similarly to the input pins. (See my comments to Sadler below).
"Each time an additional output pin was connected, a new unconnected pin would be made available" - Sadler
- I think the instance count need not be entered explicitly, but could be determined by enumerating the connected inputs and outputs. Also it seems safer to work from the actual number of connected inputs/outputs rather than considering possible consequences of a mismatch between the number of connections and an explicitly requested number of instances.
- I now think this enumeration could eliminate the need for any Multi-instance checkbox (or numeric-entry) box. Multi-instance is enabled by the menu, and activated when more than one input, or more than one output is connected.
- If input-vs-output constraints (such as one-vs-many , equal-vs-equal, many-vs-one) are needed for simplicity of implementation, these options could be offered by a combo-box. Instance count is then simply the greater of the input and output counts and one instance-index is arguably sufficient. In cases other than the above there would need be two indexes, as mentioned by Sadler: "A single module could be virtually instanced, adding input and/or output connectors as required ... where the input and output indexes are available to the parameters and modifiers are applied to each instance"
- Some annotation could be helpful reminders of the highest index number(s), and perhaps sufficient to show that multiple instances were active.
eg (0...4) on the input side and (0...4) on the output side for module having 5 inputs & 5 outputs.
- I'd be happy with just the Transforms in an initial implementation, although I'd have found use for multi-instance HueSaturation when making my projector test chart.
@Sadler yours is a great idea but a bit too great to fit entirely into my head!
Thanks for your recent response, but I'm still a little puzzled by part of it:
Too heavy for me to lift! Happy to leave it to Eric!
- Multi-instancing could be enabled by a module menu option, regardless of how the instance count is determined.
- When multi-instance is enabled the module could have brackets after the module name, perhaps including the input and output pin counts eg Scale [5:5] or Translate [1:8]. Neatly, this would appear on the module's title bar from which the option had been enabled.
- I think Sadler and I envisage that the output pins would behave similarly to the input pins. (See my comments to Sadler below).
"Each time an additional output pin was connected, a new unconnected pin would be made available" - Sadler
- I think the instance count need not be entered explicitly, but could be determined by enumerating the connected inputs and outputs. Also it seems safer to work from the actual number of connected inputs/outputs rather than considering possible consequences of a mismatch between the number of connections and an explicitly requested number of instances.
- I now think this enumeration could eliminate the need for any Multi-instance checkbox (or numeric-entry) box. Multi-instance is enabled by the menu, and activated when more than one input, or more than one output is connected.
- If input-vs-output constraints (such as one-vs-many , equal-vs-equal, many-vs-one) are needed for simplicity of implementation, these options could be offered by a combo-box. Instance count is then simply the greater of the input and output counts and one instance-index is arguably sufficient. In cases other than the above there would need be two indexes, as mentioned by Sadler: "A single module could be virtually instanced, adding input and/or output connectors as required ... where the input and output indexes are available to the parameters and modifiers are applied to each instance"
- Some annotation could be helpful reminders of the highest index number(s), and perhaps sufficient to show that multiple instances were active.
eg (0...4) on the input side and (0...4) on the output side for module having 5 inputs & 5 outputs.
- I'd be happy with just the Transforms in an initial implementation, although I'd have found use for multi-instance HueSaturation when making my projector test chart.
@Sadler yours is a great idea but a bit too great to fit entirely into my head!
![Smile :)](./images/smilies/icon_e_smile.gif)
Thanks for your recent response, but I'm still a little puzzled by part of it:
Well, that's not what I was missing, indeed it's what I was proposing when I wroteSadler wrote: ... If the module had one additional unconnected pin, this could be connected to create additional instances. Each time an additional output pin was connected, a new unconnected pin would be made available. Modules already do this for input pins. Is this what you're missing Terry?
Here we seem to be in agreement, but I may well be missing something else.Terry wrote: Suppose that, when "Multi-instance" was checked, the output pin count behaved equivalently to the input pin count. An additional output pin is added as soon as one adds a noodle to an existing output pin.
Too heavy for me to lift! Happy to leave it to Eric!
Re: Module Index Internal Parameter
The more I think about this idea the more excited I get about the possibilities. This will make it possible to make "follow the leader" / chained objects, similar to the Hypnoworm ISF https://www.interactiveshaderformat.com/sketches/1655 pretty easily using a combination of transforms and delay. Also, tunnels composed of 3D objects. ![Smile :-)](./images/smilies/icon_e_smile.gif)
![Smile :-)](./images/smilies/icon_e_smile.gif)
-
- Posts: 31
- Joined: Sat Sep 06, 2014 9:44 pm
Re: Module Index Internal Parameter
A brilliant suggestion!