Back then, the issue was that my grasshopper definition was huge and I was in the middle of production so I couldn’t quickly identify and isolate where it happened.
But I have managed to catch it “early” in the process within another file.
Please see here*:
*when the cursor goes off the screen I’m hitting recompute.
Actually, it also manifests in other parts of the algorithm:
As you can see, I must recompute to scare this bug away.
NOTE:
When I first posted about this, recomputing didn’t do anything. I actually had to go open the algorithm in another computer for it to work properly, or switch between R7 and R8.
‘No biggie’ right now, but 40 hrs later, when this algorithm grows, then it’s the scariest s$#@t ever.
Any thoughts?
Thank you!
p.s.: @Japhy - shortening the algorithm with internalized data doesn’t help, because it’ll mysteriously go away, so I can DM you the entire thing if you’re able to help.
Sorry, I should have added that I must recompute twice or thrice for the bug instance(s) to disappear. Again, when the definition gets larger, this process is (1) scary and (2) painful.
Reasons: scary because then I can’t exactly know where it starts when there are no previous warnings nor errors - painful because as you’d guess, when opening the file you must wait for it to load completely, then you must wait again after recomputing, then again.
would it be possible for you to share only what is on the left side of this area, and completely remove the right part? would it make it “non sensible” data?
What must be said, given the usual line of work, is that these bugs seem to have somewhat of a connection between Rhino 8 and the use of split tree component when handling and working with planar intersections of solid masses. Although there are no actual errors and everything is working fine and clean, at some point the bug appears, then it goes away (fingers crossed) after recomputing. However, if I delete stuff prior to and/or after the part where the bug appears, and copy that to another blank file, save it, no such bug apperas. Head scratcher.
Actually I take that back - since this bug is nasty maliciously naughty, mischievous, and kind of unpredictable then who knows maybe it shoes up when you open the isolated fragment: bug.gh (11.9 MB) - that’s one of the areas where it happens, which corresponds to the one you were requesting.
Ha, this is so silly, I just opened the algorithm and no bug manifestation. Maybe because it’s a rainy day today.
Thanks Inno.
I didn’t find anything strange there, and don’t think anyone would find anything there because data is internalized on the split tree itself, so -of course theoretically- it will always output the very same values, which do not cause the problem
what I’m thinking is something that could somehow be related to this part (which extends undefinitly to the left, don’t know what is there ), which is the portion of code that generates the path addresses used to split the tree (pic taken from your second video):
a silly question that just came to my mind because happened to me last week: on your PC, does this gh definition live on its own (fully internalized geometries) or it should always be opened with a given Rhino file containing the actual geometries (even if geometries are always the same) ?
it happened to me that I shared a GH file with geometries fully-internalized, and when the other person opened it, the result was different… after a few hourse where I only drank gintonics while cursing, it came out the issue was with Rhino tolerance: when the other person was opening the gh file, he had the default empty Rhino template opened, for which Rhino Tolerance was set to 0.01 while on my side I had a dedicated Rhino drawing containing the geometries, and my Rhino tolerance was 0.001
Tolerance and units can definitely influence the problem - I forgot to tell you the file I’m working with must be in inches, tolerance 0.001; however it’s a lost cause - as you say, and without you knowing that beforehand, still nothing happened.
This was my guess. If you now go back to Rhino, set the units and tolerance I bet there’s no bug.
It’s a curse. I deserve it.
the reason why I think no one might be able to reproduce the issue with the bug.gh file, is because the Split Tree has internalised data, and is correctly splitting the tree, so the data supplied to shatter & Company works well and will keep working well regardless of how many times it’s disconnected and reconnected
it looks like the data arriving to Split Tree sometimes changes, I assume both the Tree to be split and the Mask data are both updated simultaneously, but the result of the filtering throws-in some branches that might not supposed to be there because they were not supposed to exist in first place
let me be clear, I’m crawling in the dark, but I’m trying to point the finger to things that somehow would sound reasonable to fail in the scenario I see
it could be something related to some kind of something|something intersection that sometimes produce a data tree that is correctly split using a good mask, which was supposed to not include some of the branches that is actually allowing to pass through?
do you have any Cluster in the definition? (asking this because I know for sure they mess-up data trees)
is this yellow area the location in the definition containing the intersection components?
HOWEVER, and thank you, after you pointed this out I thought about ONE silly thing that could be the possible culprit: indices that I “manually” specified with a couple of sliders, happening prior to the Split Tree component as you guessed:
When opening the file, the incorrect items are picked from these indices. In my obvious ignorance this is odd because these indices are known to me, therefore I entered them. Nonetheless after I recompute the solutoin, the indices become correct and the corresponding items are picked. Just like that.
Open file: incorrect items are picked from indices.
Recompute file: correct items are picked from same indices.
This is why I say the data arriving to the split tree shouldn’t change.
So, instead of specifying these indices myself, I make sure they’re found automatically via closest points:
'Feels like a no-brainer, and I admit it’s my fault, somehow, but I’ll go to bed 100% convinced I’m being trolled by Rhino simply because I have BOTH versions of the algorithm opened as I type this and BOTH are working fine
This reminds me of another recent topic where you advised someone to avoid combining wires pressing shift into an input. Not sure this is related but that’s how those two indices where going into a List Item.
Thank you for your time, Inno - I guess this is the solution.
I feel you - both of your suggestions “integer + equals” and “smaller than 001” work fine. I’ll keep using the integer method.
The problem is that I opened the file and everything is normal again, without needing to recompute - never thought I’d say “hopefully it goes back to wrong again” so we keep testing.
), which is the portion of code that generates the path addresses used to split the tree (pic taken from your second video):
