There is a bug in the roof geometry when created from the script below (the only way to have accurate andle by % ). The .3dm with the roof and the curve here:
Also I had some strange deformations when I changed a bit the actual curve slightly, but I cannot reproduce now.
By the way, please, please, give the option of angle by % natively in the roof creation dialogue. It’s the standard way of measuring roof angles in Greece.
Note: the curve has to be that complex because it’s on an existing building.
i modified the curve and i get now the same result between gh script and roof from curve creation. But both exclude from the calculation the green part. The modified curve is actually the desired curve because it’s the plot line curve surrounded by other buildings of different ownership.
Actually, the plot line contains this geometry. The plot is surrounded by other buildings. So it’s common to blindly set building line and roof line by plot line. Otherwise the roof geometry either will not be valid or will overlap or intersect surrounding different ownership buildings.
Hello Fransesc, I simplified the curve as you suggested and it worked. But in my opinion the bug is something that indeed could be checked from your side.
Now I’ve changed a bit the curve in another spot. I wanted to create a curved part of this roof, following building’s geometry. The raw curve as an input, led to a calculated simplified roof. For that reason I manipulated the curve in order to come as close as I can to the desired curve for the roof. The result is that it managed to create a roof from the manipulated curve, which is close enough to the initial, based on a tolerance.
Q1: why the first raw curve in not something that roof creation function can handle?
Even though the roof was finally created (with the manipulated curve as input), I get an error when I deconstruct the roof in order to get surfaces and create structural elements based on the geomery of the roof.
The error I get is this: Solution exception:Array dimensions exceeded supported range.
Q2: can we do something about it?
I know that the curve produces many surfaces, but we need to push to precise results, despite complexity issues.
Here is a test .3dm file with the complex curve and the corresponding .gh script.
You should be able to create a roof from that curve. I’ve tried and it worked.
Just take into account that the roof can’t generated curved slopes. So in the case of curved boundaries, it tessellates it by reasonable number.
This error appears because you are generating a boundary curve with too many control points, specially in the curved part. The number of slope faces this curve generates is higher than what the roof object can handle.
I regret to say the VisualARQ roof won’t help you right now for roofs that have a curved face.
Through experimenting and diving into roof geometry, I’d like to work with the slopes more programmatically. I tested the following scenarios:
I tried to manipulated allready created roof through grips. I noticed that snapping accurately is not something that works out of the box. Also, I noticed that when moving the grip, a surface is created below the roof (check the gif). And finally when I enter the angle (in degrees) in one of the slopes (finding which slope is only doable through trial and error) then we can accurately have the desired manipulation.
Usefull functionality:
**each surface should be colored when selected through the dialogue, in order to know which surface is assigned each slope (and area).
ability to create a roof by preselecting each slope through a geometry preview. Instead of manipulating the created one, I’d like being able to create the desired one from the start.
as mentioned before % unis in slopes.
Question: angles in dialogue are in degrees, in the units resolution (calculation wise) of the document, right? Even though it displayes only two decimals**
I tried to create the roof - with % as input and degrees in the roof component instead of radians- but by presetting the slopes from the start.
So let us say that we wanted to have three slopes of 45% and one vertical.
The roof component can take as inputs a list of slopes, matching each one to a surface of the roof that is going to be created. The calculation logic is a black box. Can you tell me from which surface is the counting starting? Is it going clockwise, 1, 2, 3, 4 surfaces etc?
As you can see in the .gif, when I am exceeding some values in the angle there are some artifacts with vertical surfaces. Once again I am going blindly, I need to figure out which surface should matched with each slope either by trial and error or by deconstructing before baking the roof and playing with list item to find the desired surface and to directly point this single one to a specific slope
Questions:
**- Which is the range of angle acceptable for this case?
How is the angle being measured by roof components? As far as i understand it’s about the vertical angle, beginning from 0 when vertical we have no slope there**
I tried to take a more complex roof as input, here are the results:
The roof can be created successfully. And the more complex one as I described earlier.
As you can see, the grip manipulation now does not work. Even though in another test of mine, on this very roof geometry it was successfull. I was not able to reproduce it this time.
Ah I found it. It’s not manipulable if created from .gh script. As you can see below, if you create it from VA dialogue (not .gh) it’s doable.
If i try to preset the slopes on such roof from .gh, it does not work as expected. I could go on on this, by posting more scenarios here.
I can create the roof , from .gh, with % input, but I cannot preset the slopes matches. There is incosistency between creating from VA dialogue and from .gh definitions. This creates mismatches in the workflows. I personally believe that roof geometry consistency and control is a must. Especially when in Archicad with a button push and the roof wizard you have a roof plus its structure.
Consistency between VA dialogue and VA gh script for roof creation is the number one for workarounds and structural elements creation automations for roofs, that’s the goal.
I noticed also that when you create roof from .gh, the slopes have a numbering (by listing surfaces before bake) and when baked the surfaces have a different numbering. For instance, if a slope before baking in the .gh preview is the second of the list, in VA dialogue in Rhino after baking it’s the second from the end, something like reversing the numbering. I belive it’s important to have consistency on that.
As always, I am putting effort to give feedback in order to make VA better. This post took me about 6-7 hours of experimentation and 1 hour for writing this all down. It’s not well documented, so it would be great if you could dig for missing boldy questions throuth this post.
Hi @Gabriel_Bouzelos I appreciate the time and effort you have taken to report all these issues regarding roofs. For sure this will help us improving this object and its functionality in future versions/updates.
The deconstruct roof component is meant to give you the same input data used to create the roof: the roof boundary or surface (in roofs created from surfaces).
If you need the top surfaces of the roof, the VisualARQ Explode component is the best option. You also have the Roof explode component which will give you the individual slabs that compose the roof.
Yes, roof slope extension arrows are a bit inconsistent eventually. We need to fix these cases.
Agree. There are plans to make something that helps identifying the roof slopes from the properties panel.
You can do that already, in roofs inserted in the model from rectangular boundaries (not those created from curves). While you insert them, you can modify the slope of each slope (ignoring here the issue of identifying the slopes):
I’ll get back to you when developers fix this. I can’t help you further with your case if this doesn’t work as expected.
(The slopes are defined in radians in GH)
The order of the slopes is “a bit” unpredictable, I agree. Depending on the boundary direction and the insert point you may get one order or another. This is how it currently works (circle defines roof insert point):
I’m not sure if this issue with roof grip manipulation has to do with the fact the roof is created from Grasshopper or not. I’ve seen cases where it doesn’t work either with roofs inserted directly in the model.
Theroetically this should work fine now. But I see it doesn’t. We will figure out about these bugs and get back to you when everything works as expected.
