Hi,
i must be missing something important, but i couldn’t figure it out so i am asking for help. In this script i attached, there are two simple zones for which the adjacency is not getting solved with the solve_adjacencies component. The adjacent wall doesn’t turn to “surface”, it just stays “outdoors”.
Any advice? thank you for your time
problem with adjacency.gh (466 KB)
Iason,
I don’t have time to open your model at the moment but have you seen the tutorial video that explains the geometry rules for solve adjacencies?
https://www.youtube.com/watch?v=cDvBWDA0aF0&index=10&list=P…
-Chris
Hi Chris,
yes i have seen it before, and i was able to make it work in the past, but something is wrong particularly in this file, anytime you can look at it it’s ok!
thank you!
Hi!
I looked a bit at this and it puzzled me too, there might be a bug here.
Since you have sent me the Rhinofile, which is not posted here, I could recreate the problem. But I can only recreate the problem in this rhinofile, not when running the script you posted here without the accompanying geometry (btw the script you posted here lacks some geometry… 
You had built your geometry 60 kilometers from the origin point. This might be a cause for the bug, but correcting this in rhino did not do the trick either.
In the attached rhinofile, it seems the solve adjacencies works fine when the smaller surfaces of a box are aligned, not when the larger surfaces are.
I posted the file here if anyone is interested to look closer at it, otherwise I would recommend rebuilding the rhinofile. Copy only your geometry to a new file and see if it works.
problemwithadjacency 2.gh (494 KB)
Problemswithadjacency 2.3dm (86.6 KB)
Iason,
You did not internalize all of your geometry in your GH file so I cannot run your script:
You will either have to provide your rhino file or internalize the geometry.
-Chris
Hi Chris,
i am sorry for that, i forgot to internalize, now i checked with what Ludvig said, the rhino file was drawn at a long distance from the origin point, i move it to the origin point, reassigned the surfaces and it now works. I think it was the distance thing. Sorry for the trouble, i am a bit new to this, thank you
Ah, I should have read Ludvig’s post before writing back here. Never forget the importance of refreshing the browser.
My guess is that it is related to the rhino tolerance and how Rhino stores the coordinate data. Because Rhino stores all coordinates as floating-point values (that I believe are 16-bit), it only keeps the point data accurate to a certain number of decimal places (1 of 2^16 different values). If your coordinates get so far from the Rhino origin with so many digits, the accuracy of the coordinates might become coarser than the Rhino model tolerance, causing Honeybee components that use this tolerance to behave weirdly.
Moving your geometry closer to the origin is the safer solution but you could have also made your Rhino model tolerance coarser (by typing the ‘Units’ command in the Rhino toolbar and changing the tolerance) or you could have adjusted the tolerance_ input of the “Solve Adjacencies” component to get it to work.
-Chris
Chris,
this is really good knowledge that you are sharing, i checked the tolerance values as an experiment, and you are right, adjusting the tolerance in the “solve adjacencies” components works.
Now keeping the drawing closer to the origin is the safest solution according to what you said, so that is the lesson! I had the plan layout imported from autocad and it “landed” somewhere completely off!
I appreciate that you clarified things, case closed!
T h a n k y o u !