Fix `ViewerNode` 3D Preview #70

New Issue

Closed

opened 2024-05-19 09:05:51 +02:00 by so-rose · 1 comment

so-rose commented

2024-05-19 09:05:51 +02:00

Owner

While we had a slower InfoFlow operation, during TransformMathNode implementation we noticed how absurdly much wasted work the DataChanged is doing. This amplified especially by the new blfields_deps work we did, each of which also does a DataChanged, incidentally.

We recalled thatactive_kind=set() really ought to stop propagating for DataChanged, as when no FlowKinds are changed, then... Well, no data is changed :).

So why didn't we do this before? The problem arises with the Viewer node: It is the only node that must know about any DataChanged from anywhere in the graph, so it can start a 3D re-previewing procedure.

The problem is, this is all expensive as all gosh, and to boot, runs in the very sensitive "adjust-preview" hot loop. It's about as anti- as an anti-pattern can get.

By implementing propagation-stop, we needed the Viz node to have a dummy-output-method for its Preview output socket, so that the Viewer node would get told about a new plot (and fire ShowPlot on the linked node, which itself now also stops immediately after the first node).

So plotting is fine. What isn't fine is 3D preview: DataChanged related only to preview alterations never make it all the way to the Viewer, and honestly? They shouldn't. It's a ton of noise/garbage in a really sensitive hot path, which has 0 bearing on real results; a brute force method of teleporting a boolean.

The issue is what to do instead. It's clear that the data flow semantics just aren't suited for the 3D preview. The question then becomes, what mechanism is? No easy answers. Probably involves the node tree.

While we had a slower `InfoFlow` operation, during `TransformMathNode` implementation we noticed how absurdly much wasted work the `DataChanged` is doing. This amplified especially by the new `blfields_deps` work we did, each of which also does a `DataChanged`, incidentally. We recalled that`active_kind=set()` really ought to stop propagating for `DataChanged`, as when no `FlowKind`s are changed, then... Well, no data is changed :). So why didn't we do this before? The problem arises with the `Viewer` node: It is the **only node** that must know about any `DataChanged` from anywhere in the graph, so it can start a 3D re-previewing procedure. The problem is, this is all _expensive as all gosh_, and to boot, runs in the very sensitive "adjust-preview" hot loop. It's about as anti- as an anti-pattern can get. By implementing propagation-stop, we needed the `Viz` node to have a dummy-output-method for its `Preview` output socket, so that the `Viewer` node would get told about a new plot (and fire `ShowPlot` on the linked node, which itself now also stops immediately after the first node). So plotting is fine. What isn't fine is 3D preview: `DataChanged` related **only** to preview alterations never make it all the way to the `Viewer`, and honestly? They shouldn't. It's a ton of noise/garbage in a really sensitive hot path, which has 0 bearing on real results; a brute force method of teleporting a boolean. The issue is what to do instead. It's clear that the data flow semantics just aren't suited for the 3D preview. The question then becomes, what mechanism is? No easy answers. Probably involves the node tree.

so-rose added this to the Robust Simulation milestone 2024-05-19 09:05:51 +02:00

so-rose added the

bug

physical

architecture

labels 2024-05-19 09:05:52 +02:00

so-rose referenced this issue from a commit

2024-05-19 09:06:44 +02:00

feat: transform node w/sane `DataChanged`-chaining

so-rose commented

2024-05-28 12:55:15 +02:00

Poster

Owner

We implemented PreviewsFlow, a new FlowKind that manages all of this. The way it interacts with the caching logic ends up being very elegant and optimized.

To prevent duplicate plot invocations, this also led us to perform aggressive DataChanged-narrowing by-FlowKind, to indirectly use depends_on logic between BLFields to start the DataChanged-narrowing right on the sockets themselves, and to upgrade the Viewer node to properly support live values/previews without excessive overhead.

We implemented `PreviewsFlow`, a new `FlowKind` that manages all of this. The way it interacts with the caching logic ends up being very elegant and optimized. To prevent duplicate plot invocations, this also led us to perform aggressive `DataChanged`-narrowing by-`FlowKind`, to indirectly use `depends_on` logic between `BLField`s to start the `DataChanged`-narrowing right on the sockets themselves, and to upgrade the `Viewer` node to properly support live values/previews without excessive overhead.

so-rose closed this issue

2024-05-28 12:55:16 +02:00