Apologies for the vague title, but this seems the most appropriate explanation of what’s happening.
When performing solar analysis in Rhino/Grasshopper with the LB Direct Sun Hours component, if I have my geometry far from the origin (generally a result of inheriting shared coordinates from a Revit model), the LB Create Legend component creates a phantom object at the Rhino World origin, causing the extents of the model space to be stretched. This has the unfortunate affect of causing the mesh visualisation to glitch.
This is directly reproduceable by modelling anything far from the world origin, and then placing a LB Create Legend component onto the Grasshopper canvas.
My solution for this currently is to move all the model elements to the world origin. This is not ideal, especially when collaborating with other programs, but we make it work. Another solution would be to have a second version of the script without the LB Create Legend Component, but I use the legend, as it is derived and built from the script. I’ve tried inputting a base plane into the LB Create Legend component, but this changes nothing with the extents.
My question is: is this a bug, and is it fixable?
You can set the base_plane_ input of the LegendPar component to anywhere you need/want. The default is the world origin [0,0,0] as you mention.
Though i recommend using the more flexible LB_PreviewVisualizationSet component to place the legend as a 2D layer on the viewport.
-A.
Apologies, forgot to clarify that even setting the base plane to a different point still causes the issue, something is still supposedly present at the world 0,0,0, even though the legend itself moves visually in the Rhino Viewport. I’ll investigate the PreviewVisualizationSet component and report back, thank you for the quick reply!
After quick investigation, the LB_PreviewVisualizationSet produces the exact same ‘bug’ as the LB Create Legend component, something is supposedly placed at the origin, even though nothing is visually there in the rhino window. I’m guessing internally the components are using the 0,0,0 world coordinates as a reference point for something, even though we can’t see it.
Please see attached image of the issue using the PreviewVisualizationSet component, you can see all layers are on, nothing is hidden, but zoom extents still believes something is at the origin.
You can upload both files [Rhino + GH] so people can check and suggest more effective suggestions.
Beforethat, try to select all [ctrl+A} in rhino, unselect [manually] the geometry you are sure is correct, and delete the remaining ones. I suspect there is something really small that is included in the analysis and it is close to the origin.
-A>
The files I’ve taken a screenshot of were created just now to demonstrate the issue. I can consistently reproduce these results with clean files, on different computers. If I disable the grasshopper file, or open a blank one, zoom_extents in rhino immediately zooms on the modelled elements, which makes it more likely it’s something involving the ladybug components.
Working just fine for me.
-A.
unnamed.gh (9.5 KB)
Untitled.3dm (23.4 KB)
Does zoom extents only zoom on the rectangle, or does it also include the origin? I just made these file fresh just to send now. There is nothing hidden. I’ve attached images to show the difference between having a grasshopper legend component or not having one on the canvas
I believe you should report an issue to the Rhino discourse.
Your file indeed has an issue with the ZoomExtents. It even “spoiled” my Rhino session [after opening your file I opened a new one and it behaves as your case]. Closing the Rhino session makes the ZoomExtents work fine again. Didn’t find any setting related to this.
-A.
