I have a very convoluted script that I’m rewriting, and mysteriously, if I set one slider to a particular value, ALL objects in the perspective view disappear. (Notably, the ortho views still draw fine.)
I expect Grasshopper preview geometry to vanish if there’s some problem in my script, but even the baked objects in the file aren’t drawn. If I right click the layer and “select objects” then I get a gumball, but everything is invisible.
I’m a little flummoxed that this is even possible: how can Grasshopper “turn off” drawing in a particular view? It sounds like a bug. If anyone has any insight, please let me know, it might help me track down the problem.
It’s probably a corruption of the clipping box. Before a viewport draws it needs to know the size of all the shapes it’s going to display so it can set up the z-depth buffer. Grasshopper needs to add the bounding box of its own preview shapes to this central viewport clipping box and if it gets set to either an enormous or invalid box that may affect the entire display.
It’s obviously a bug, I shouldn’t be setting an invalid or huge box, so I’d love to have a way to repeat that.
The problem: I’m passing the Arc3Pt component 3 parallel lists of points (start, mid, end). Many of them are just points in a straight line (so in those cases the component just creates a line, with a warning) and many others are legitimate arcs. (I’m creating lines and arcs that follow a sort of ribbon surface, starting flat, swelling to curved, then flattening back out.)
But one set of “linear” points (#7 in the lists) creates an enormous circle (with a radius of 6.4204e+21 mm!) instead of a line. Whoops. Seems like a tolerance issue. And explains the overly huge bounding box.
But here’s the other mystery: When I internalized the point data, copied out the offending bits, and pasted it all into a new grasshopper file to post here…it didn’t happen. Hmph. So something about this is grasshopper-file-specific as well. So the file I enclosed here is actually my crazy enormous convoluted Grasshopper file…but with everything deleted EXCEPT the offending bits.
As I understand it, Grasshopper doesn’t have “private” tolerances, so now I’m double-flummoxed. (Which is incidentally fun to say.)
Thanks for investigating, I’m looking forward to enlightenment.
If the interior point is (almost) collinear with the end points but not in between them, then you’ll end up with an absolutely enormous arc. One of the drawbacks of defining arcs this way.
I’ll see about repeating that and ways to filter out such suspicious bounding boxes.
Thanks for uploading the files.
The “mid point” is indeed between the end points…here’s a screen shot of the 6th points in the list (good) and the 7th (bad), and their resulting arcs. Note that the “bad” one doesn’t even go through the points!?
Looking forward to hearing if you can reproduce this in the files…
Hello
I didn’t go through all the discussion I often have this problem that seems due to geometry going to the other side of the universe, so I lost the visibility of my “normal” geometries. In order to suppress that I didn’t find better solution than not generating impossible geometry.
A Grasshopper/Rhinoceros filter would be better but perhaps you’ll have to wait a long time.
David did say he’ll look into repeating this issue
Primary focus is on Grasshopper 2
At any rate, …
I think I was able to extract a single 3-point combination that creates a huge arc and messes up the Rhino viewports. So that he doesn’t forget, I put this on David’s list as RH-79285 Grasshopper: Arc3Pt result and view issue
Thanks,
-wim
