Solution exception: Input must be of type Color: ‘nonetype’ object has no attribute 'r’
I’ve tried different objects as context and geometry, I’ve rebuild surfaces, deleted the legend-parameter connection and I have internalized geometry, but none of it helps… Any suggestions?
thanks
anders
energy production in LBT-20210227.gh (144.7 KB)
It’s definitely an issue with your geometry @anders (maybe a zero-area face?). I can’t really tell what it is because you internalized the geometry in the component input, meaning I can’t see it in the Rhino scene. If you internalize it in a geometry parameter component instead, maybe we can figure out what is going on.
I have just moved to my imac at home and see two different errors, but not all the time.
I’ve asked Rhino to look for bad objects and found none. I have manually selected every face that I’m testing…
Oddly it seems to come and go depending on the grid size.
When it works I do however see one other strange thing…the legend/scale does not reflect the range on the face/faces I’m analyzing. The colors on the faces are way down on the scale and I have no facades with the the high incidence indicated in the scale…
I’m still struggling with my simulation and just can’t get it to do what I need for some weird reason…I would appreciate any wizzarding insight that may be available.
I’ve extracted and rebuild volumes and surface and keep getting errors…I’ve attached both a rhino and the grasshopper file.
ladybug problem.3dm (308.2 KB) ladybug problem.gh (147.1 KB)
thanks
anders
Hi everyone,
thank you so much for all these great tools and for the current major updates!
I’ve, however, discovered that the Radiation analysis in LB 1.2.0 is way more sensitive towards the quality of the input geometry than in the legacy plugins. I’m currently working with a LOD2 input geometry of a city and am unable to use the 1.2.0 version as I’m confronted with the error message “1. Solution exception:Attempted to divide by zero.”, the same geometry works fine in the legacy version.
After testing it on a simple box, it seems that the minimum edge length of a BrepFace cannot be shorter than 1m, it doesn’t seem to be related to face area or grid size. Is this something that could be easily solved, or am I missing something?
Thank you!
Hello again,
I did some further tests and the “error” with LB 1.2.0 is also related to the distance from the 0 point. Attached you can find a screenshot of the GH definition, with Box1 = 0.5x0.5x5m and Box2 = 0.8x0.8x5m. and a distance from 0 of ~ 2959367m.
Box1 works fine in LB 1.2.0 and in LB Legacy, Box2 only works in Legacy.
Overall, I’m aware that such a huge distance from 0 is not ideal (and I therefore put the “error” in exclamation marks) yet I’m curious why this wasn’t an issue up to now with the legacy plugin.
Thank you!
I’m quite sure it is not the geometry as I have tried to replace, rebuild then numerous times and have even tried in a separate file…
Could it be because my model is in millimeters and not meters?
thanks
anders
Large distances from the Rhino origin have always been an issue because of how computers store floating point numbers (the tolerance of floating points is really only reliable down to a factor of 1e-9 to 1e-12 and there’s a hard limit around 1e-16). Essentially, you loose the ability to meaningfully represent the scale of buildings when the model as a whole represents scale that is well beyond it. This is partly why Rhino has you choose a template based on cases of “a truck or larger”, etc.
Usually, you will start to experience problems representing the building scale when you are something like 1/8 of the circumference of the Earth away from the Rhino origin (3,000km is around this). So just keep your model to within a few hundred kilometers of the origin and you should be fine.
Also, your _geometry is still internalized inside the radiation component @anders but, when I connect up other geometry from your model, it runs fine:
