I’ve encountered what I believe to be a bug in Gh Paneling Tools. In my example, I tried to divide by length two surfaces with the dimensions - 1.2m x 2.4m. Unfortunately one of my surface had a dimension shorter than my desired length and so Paneling Tools annoyingly just ignored that surface. So I tried a workaround wherein I extracted the length & width of the surfaces beforehand and made a condition wherein if any of the them had a shorter length or width than my preferred dimensions, then it would automatically use the actual lengths as a divider input. That way I always get a quad grid panel. When I tried it worked for a while but now seems to fail. In conclusion I would like to request a feature wherein if the surface is too short to be divided then it should not ignore it, rather, it should automatically divide it by one. Just like in divide curve by length, the curve is automatically divided into 1 when the length cant be divided into 2 or more. I’ve uploaded the script below. Thanks
Thank you, Rajaa. Sorry to sound hasty but when do you think this could be implemented? Also what are your suggested workarounds for the time being because my workaround seems to fail given the fact that Paneling Tools still has problems dividing the length by one even though I gave the exact value to divide it by one. For example, I entered .0.56 meters for the Ulength input as it is the actual Ulength of my surface and still Paneling Tools could not accurately divide it, instead of dividing the surface exactly, it creates an excess surface that is very, very small. When I checked my cells, I found that it had created cells that are very small in which it’s areas are in the decimal range. I think this has to do with accuracy and because the Ulength is near the edges. I hope I explained my situation coherently. Thanks
Thank you for your quick response and the workaround. It seems to work perfectly until I make it’s reference point the center of the surface. I attached the example.
Thanks for the response. I tried this Latest Workaround you gave but unfortunately it does not solve my problem when I apply it to my custom script. I don’t know why it has an error. As for the Previous Workaround you gave, it work quite fine until, again, there was some tolerance issues. I’ve given the exact Ulength value and still it won’t divide to 1. I’ve attached the files to show my problems. It would be much appreciated it if you can give a solution to this because I really need to finish a lot of detailing with limited time. I’m hoping for the best.
Ok, but I’m not able to use your definition because some plugins are not downloading. Can you simplify the sample to point out the issue so I can open at my end?
I’m sorry, that component is Unify Uv’s that I downloaded in Food4Rhino. It’s important for my script and I can’t really make a custom node. Do I have permission to upload directly the grasshopper assembly file so you can paste in your grasshopper components folder?
Ok, I think I got it this time. You needed to adjust the reference point from center to the edge in the case when distance in bigger than the domain length.
Try the attached. I tested it on your skinny surface. DivideDistance_RI_C#.gh (14.8 KB)
I’m very grateful for your replies, it works for the most part but it fails when I select multiple surfaces. In the image one is clearly omitted and in total , three surfaces are omitted. My goal is for multiple surfaces at once.
Also what are your suggested workarounds for the time being because my workaround seems to fail given the fact that Paneling Tools still has problems dividing the length by one even though I gave the exact value to divide it by one. For example, I entered .0.56 meters for the Ulength input as it is the actual Ulength of my surface and still Paneling Tools could not accurately divide it, instead of dividing the surface exactly, it creates an excess surface that is very, very small. When I checked my cells, I found that it had created cells that are very small in which it’s areas are in the decimal range. I think this has to do with accuracy and because the Ulength is near the edges. I hope I explained my situation coherently. Thanks
