You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some of our core regions manage state, even if they don't have "Manage", "State" or "Lifetime" in their names.
For E.g. a ForEach loop allows to use process nodes and will instantiate the patch inside the region once per index -> All process nodes in a ForEach exist several times.
Behavior over time:
Only when the count goes up from frame to frame new states will get created. The other ones get reused.
And when the count goes down Patch-States / "Slices of the ForEach" will get disposed of.
So a ForEach region is as much a lifetime manager as ManageProcess, just for many instances of the patch (one per index).
However, currently, the patch instance gets also disposed of when the user feeds False into the Keep pin.
Proposed Refinements
option "Always Keep State". We'd be able to use the Keep pin to decide what data shall go into the splicers, but we'd always keep the state of the region for this index. Currently, the state of the region gets thrown away, which sometimes feels wrong.
option to Synchronize to a key: It feels off that we sync to an Index. It would make more sense to sync to a Key.
If the Key is new -> Create a patch instance. If the Key is known reuse the patch instance. All Keys that disappeared from one frame to the other result in Disposing of the patch state. This is currently done in so-called Synchronizer regions, which no one uses or knows of as it's too hard to explain what they really do and why you need them. My intuition now is that their functionality is more natural than just using the index as the key.
Variations for determining the key:
"Use All Splicers as Keys": a tuple of all splicers is used as a key. We wouldn't need to pick one slicer.
Introduce a special keyword ("Slice Key", "#" or "key"..). When using this keyword in the splicer name this one gets used as the key.
If the compile time type is an IVLObject we could use the Identity as the key (instead of the reference).
We could throw away the complicated synchronizer regions and when a user creates a new ForEach enable this new behavior as the default.
Model-Runtime & Model-View synchronization, which is getting more and more common would get a lot simpler than current approaches.
The text was updated successfully, but these errors were encountered:
I have some recollection that I did a branch once where the loop behaved like described but it was disregarded as no use there are sync regions doing that ;)
will need to dig in our history how it was called..
Introduction
Some of our core regions manage state, even if they don't have "Manage", "State" or "Lifetime" in their names.
For E.g. a
ForEach
loop allows to use process nodes and will instantiate the patch inside the region once per index -> All process nodes in a ForEach exist several times.Behavior over time:
Only when the count goes up from frame to frame new states will get created. The other ones get reused.
And when the count goes down Patch-States / "Slices of the ForEach" will get disposed of.
So a
ForEach
region is as much a lifetime manager asManageProcess
, just for many instances of the patch (one per index).However, currently, the patch instance gets also disposed of when the user feeds
False
into theKeep
pin.Proposed Refinements
option "Always Keep State". We'd be able to use the
Keep
pin to decide what data shall go into the splicers, but we'd always keep the state of the region for this index. Currently, the state of the region gets thrown away, which sometimes feels wrong.option to Synchronize to a key: It feels off that we sync to an Index. It would make more sense to sync to a Key.
If the Key is new -> Create a patch instance. If the Key is known reuse the patch instance. All Keys that disappeared from one frame to the other result in Disposing of the patch state. This is currently done in so-called Synchronizer regions, which no one uses or knows of as it's too hard to explain what they really do and why you need them. My intuition now is that their functionality is more natural than just using the index as the key.
Variations for determining the key:
We could throw away the complicated synchronizer regions and when a user creates a new
ForEach
enable this new behavior as the default.Model-Runtime & Model-View synchronization, which is getting more and more common would get a lot simpler than current approaches.
The text was updated successfully, but these errors were encountered: