Content Cache occasionally randomly removes objects while pushing

Serengeti (Rhino WIP)
, ,
1

This is very much a Heisenbug, but I find that Content Cache occasionally removes the objects that I am pushing or even rarer does not delete update the old geometry as I push new geometry. As a result of the way I set up the script to only recompute changes, when I have missing geometry, I setup the logic such that if offsets are missing, all offsets pertaining to the centreline curve have to be recomputed. And for some reason unbeknownst to me, this then cascades in many offsets randomly disappearing as though the data is mismatched (but there’s nothing other than the Content Cache that could affect the data).

Random data deletion
But sometimes part of the data seems to be randomly disappearing as seen in the video and screenshot below.

In the screenshot below, you can see that the green curves (part of the Unmodified Rhino Referenced Curves) are preserved while the red curves are deleted (though they were in Rhino before pushing.)

image
image1920Ă—1035 172 KB

Steps to reproduce
I’ve been witnessing this for over a year by now and its driving me absolutely nuts. The easiest way to force the issue is to use Match Properties the encircled curve on the Street - Centrelines’ layer.

Guide
Guide1920Ă—1037 187 KB

if it doesn’t pop-off immediately, then try and use the Match Properties command on another curve (as per the video). Though, the issue does also appear on manual pushes, but is way more noticeable on automatic pushes.
test_Push-failure_trimmed_smallest.gh (92.0 KB)
test_Push-failure.3dm (1.2 MB)

2

Hi Intous,

There is a lot going on here, is it possible to repeat the issue with a simpler definition?

3

I’ve been trying that for the longest time, this is probably the shortest I can make it. It’s just about the pushing of the lines, the red group. The rest is computing things that are required for the offsets but do not influence the result or I would have noticed by now.

image
image1856Ă—751 70.6 KB

test_Push-failure_trimmed_smallest.gh (92.0 KB)
E1: Got rid of a bunch more R9 WIP Offset bug workaround stuff.
E2: This is the absolute smallest, I think.
E3: Got it even smaller, this file only requires Pufferfish now.

4

@Japhy
Is this manageable for you now? The bottom white group (right besides “Part where the issue is at”) is just for trouble shooting, but you could also remove that too.

In short, the first horizontal group to the left sets attributes for the curves I’ll be offsetting.
The second one computes the offset distances.
The third one looks for curves that changed and offsets those that did and pushes the newly computed and referenced offsets.

5

I also do want to add that flattening the input for the Content Cache and using Unflatten Tree to rebuild the data structure has thusfar seemed to resolve the issues, which leads me to believe that Content Cache is somehow susceptible to data structure changes in its inputs for determining whether or not to automatically push data.

1 Like
6

Thanks, we’ll take a look to try and understand what you are doing, how you are doing it and why you are seeing these results.

1 Like
7

There is a lot of advanced Data Tree management going on your definition. Is it absolutely necessary to do this all in one gh definition? I’ve always preferred to do smaller targeted definitions instead of wrangling data trees in a rube goldberg definition.

I’ve tried this a few times not seeing the error as of yet. Am i missing something?

8

You should pick a curve on the “Street - Centrelines” layer that has offsets associated, that one doesn’t. So it changes the street type to one that has no offsets, so that’s to be expected. Try and pick the curves that I showed in my videos.
Pick one of the Street Centrelines I have highlighted in red:

image
image1920Ă—1165 141 KB

I understand, but I don’t see any other option as I need the inputs and outputs to create other objects. From the Offsets, I create surfaces, which I can then extend to create the correct roads. Then, I can retrieve the surface outlines and create the building plots from those, etc. (I have yet to piece back some parts of the script so can’t show the rest). So there are a lot of steps involved and the way I get it to work, it is real-time and allows me to leverage already computed data and re-use that.

9

Here’s another one, there are two sets of 6 surfaces, I push the data and one surface is not present after pushing:

10

Can you share a reduced grasshopper defintion of this?

11

Thing is this is part of the extension of the previous script. So its all driven by earlier content caches, and reconstructed data trees so the part that drives this is what I have highlighted here:

image
image1564Ă—1096 241 KB

And it involves pretty complicated data matching techniques that I can’t simplify. So I think your best bet is to look at the script that I shared earlier.

Solution
Since it has something to do with the data-structure (I can resolve the problem from appearing by changing two components). I can share what might cause the problem (video time-stamps below the video). Maybe someone can think of a different method to reproduce the issue.
Note that there is no difference between Pushing the Push button on the Content Cache or letting it run automatically.


0:00-0:30 - I change remove the principal input option and change the trim tree so the data is again sorted into two sets of surfaces in {2;0;0} and {2;0;1}
0:30-0:50 - You can see the script recomputes both sets of surfaces when I delete all of the affected surfaces from one branch or both.
0:50-1:00 - The problem emerges when I delete the surfaces individually.
1:00-1:15 - I solve the problem with the data structure.
1:15-1:30 - The problem keeps persisting until I delete all input data that is referenced from Rhino (at D4, D1 is recomputed surfaces, D2 is for recomputed surfaces constructed in a different manner, D3 is always empty and could have been disconnected).
1:30-END - With the referenced data deleted, the Content Cache is reset, deleting the surfaces one by one no longer causes the problem that one surface is not pushed.

Note: {2;0;0} and {2;0;1} always contained the same surfaces, but at {0:48-0:49}, when the data is pushed, one of the D2 inputs shifts to {2;0;1}, causing there to be 7 surfaces in the branch, but thereafter the data is sorted on reference and back to 6 on both branches. The principal input prevents the surface from shifting branches. And that somehow fixes the issue. So it very much depends on the data structure rather than the input surfaces.
Similarly, flattening the output data also solves the problem:

1 Like
12

I usually enjoy some grasshopper trouble quiz but I’ve now downloaded a few different versions of your scripts and none of them looks like the following screenshot from the post above. So I’m out of here.

13

@martinsiegrist, sorry for the misunderstanding.
I have shared two different problems in this thread and I didn’t want to share the script for the second way I could cause the same problem because the script is rather involved (and has a quite a few plugin requirements without cleanup).

With the script and Rhino file in the first post (reattached below), are you seeing offsets disappear when you use Perform Match Properties on Curves on the Street - Centrelines layer if you follow these steps:

  1. Delete the Street Offsets layer to reset
  2. Pick the curve to change on the Street - Centrelines layer according the video below:
  3. Pick one of the target curves on the Street - Centrelines layeras per the video (they should have a different set of white offsets surrounding them than the current set in the Street Offsets layer).
  4. This video shows the correct behavior, but when the issue occurs, you should see the curves highlighted in green jump across the screen to other streets that shouldn’t be affected and haven’t been matched.

test_Push-failure_trimmed_smallest.gh (92.0 KB)
test_Push-failure.3dm (1.2 MB)

14

image
image1022Ă—414 11.6 KB

The definition contains two components from Pufferfish which I don’t think are necessary.

Here’s my no puff’ version:

test_Push-failure_trimmed_smallest no-puff.gh (94.8 KB)