Hi ,
I am trying to create walls by section using Arqishape 3d , but there is an issue occurring
at walls corners,
the problem occur when the width of the wall is very same (like .05 meter) , but the when the wall width is big ( = 1meter) then it works ( i changed the tolerance but the problem remains)
appreciate if any one advise on the matter .
arqishape test.gh (7.3 KB)
I checked out your grasshopper file. Although mine was able to produce the geometry with no problem, when I made the rectangle dimensions smaller than or equal to 0.01, it gave the error just like you mentioned.
Sadly, I know the cause of the problem and it is what you suspected. Because I gave a fixed value to all the tolerances of operations like Intersection, BooleanDifference, BooleanUnion etc., when you change the tolerance from Rhino, it doesn’t change the tolerances of the methods I used in ArqiShap3D.
This was one of the things I wanted to fix in the future versions. I don’t think I can easily write a quick fix because I have used these methods a lot (methods that require tolerance values) throughout my code. And I haven’t still figured out how to implement it.
If it is possible for you to scale up your entire model, I don’t think you will run into any problems related with tolerances. But if what you’re working on doesn’t allow you to do so, maybe I can try to help in another way?
Appreciate if you can solve at the soonest because it is good addon.
For now we it is difficult for us the to change the units in rhino because all our models are based on meter unit.
Hope you can solve very soon
Thanks in advance
I will see what I can do… Because there are over 15000 lines of code, and these methods are used throughout, I hope I won’t run into any problems or break the code in any way. But I will look into it soon.
Hi,
I was able to solve the tolerance issue and uploaded the solved version as v0.2.1. During the process, I broke the code for Object difference component and Staircase components but I was eventually able to fix them. Object Difference even works better now.
If you will come across to any bugs, if you could report them, that would be super helpful. (Because I have changed so many methods and didn’t get a lot of chance to try all the components again to check if I have broken any other parts of the code.)
Hope this solves your issue.
I’m so sorry!
I just realized that although I fixed the tolerance issue, I still didn’t fix the unit issue! Because, I developed all the tools in ArqiShap3D while using “cm” as the unit in my Rhino Document and didn’t consider an adaptive unit system, modelling algorithms for all the other units is probably broken. For example; a unit vector which has the magnitude of “1” in Grasshopper, is actually 1 cm in the Rhino space. So if the unit is changed to meters and the entire model is scaled with 0.01, then the same unit vector’s dimension in Rhino space actually becomes 1 meter! As a result, all the intermediary geometry (which is used while modeling any kind of geometry) that’s produced in ArqiShap3D components and which also use values like the unit vector; gets out of proportion. (Which would cause huge problems throughout the entire codebase of ArqiShap3D!)
So; I’m aware that the last update won’t probably solve your problem and it is now apparent that this is not an easily fixable issue within a few hours and because I won’t be able to work extensively on ArqiShap3D for a few months due to my other projects, I think I will just add a note to food4rhino page and call it a day.
I’m sorry I couldn’t help, and hope that you can find a workaround to your problem while I eventually (and hopefully) start working on ArqiShap3D again.
@ofkurtARCH
Ok no issue , but in this case I think that mean the previous version will be better , isnt it?
If you’re using meters in Rhino, I think the current version should work better but I’m not exactly sure. While using meters as your Rhino unit, were you able to use the staircase component and has that changed with the 0.2.1 update? If it hasn’t changed, the newer version should work better in my opinion.
Also; I checked the updated version again recently. It seemed like most of the components were working fine except for the staircase components. I was also able to fix the staircase components fairly quickly to work with any Rhino unit. But after further testing, I discovered some bugs in the wall component. I don’t know if it’s due to units as well or if it’s just my algorithm. It seems like I might be able to update a more stable fix in the coming days.
Hi again,
I was able to fix the unit issue and uploaded the fixed version. Hope this solves your (and potentially many others) problem. There might still be some bugs, so any feedback is welcome.
@ofkurtARCH Glad to hear that , I will review and advise if any further issues might occur .
Actually, there are 2 wishes, I hope you add for the walls component which I think both are essential 
1- the ability to provide different wall thicknesses ( currently, the user is only able to make one wall thickness for every wall base curve , So for example the user could have corner where I have 10cm wall meeting 20 cm wall) , even more , now if I enetered list of more than 1 thickness , then the whole walls is duplicated using 2 thickness sizes.
2- Add alignment and offset parameters (center , right , left alignment ) which is essential for every wall tool I used .
thanks for again for great tool .
regards
@ofkurtARCH it seems the unit tolerance issue has been solved.
thanks 
@ofkurtARCH moreover ,I am attaching here example file diffierent wall thickness feature issue , if you can do this , it will be really awsome .
different wall thickness test.gh (11.7 KB)
Actually, wall component in ArqiShap3D can solve both of the problems you’re facing.
1- The reason I’ve separated the wall modelling components in to two different groups (WallData and Wall Model) is to be able to solve the intersections between walls with different wall sections. If I were to make one component to model the walls, then it would have been much harder to provide different wall sections to each of the wall base curves that are provided to that component. Now, you can use a different WallData component for each of the wall types with different wall sections, and plug all of them into the same Wall Model component and the Wall Model component solves the intersections between all of the plugged in walls.
2- For the “WallData from Wall Section” component, alignment of the wall section according to the wall base curves can be adjusted by changing the position of the “wall section reference plane” (or point). For the “WallData from Dimensions” component; you can change the value of “Plane origin of Wall Section” parameter to an integer from 0 to 2, which changes the position of the wall section from middle to right or left of the wall base curve.
I have looked at the grasshopper file you’ve sent and uploaded a solution to both of these issues. The reason why it duplicated all of the walls in your grasshopper file is because the thickness and height parameters inside the “WallData from Dimensions” component are “item access” type parameters and not list or tree access type parameters. Which means that the component acts as if each of the items provided to these parameters are in a separate tree branch and calculates the solution according to that. I made it this way because I am not expecting anyone to provide different wall thicknesses into the same “WallData from Dimensions” component because it would be hard to keep track of which curve is assigned with which thickness value (which is the reason I made a separate component to assign wall sections to wall base curves, as I mentioned above).
Hope this helps
different wall thickness test_SOLUTION.gh (17.6 KB)
Hi @ofkurtARCH thanks for your last note and fruit feedback.
I just noticed some issue with the wall alignment location as per your above note .
if the wall base curve is higher than xy plane , then the wall will not be created at the same curve hight .
I attached example file for the issue .
regards
