Grasshopper

algorithmic modeling for Rhino

This is a continuation of a previous post on the split building mass component:

http://www.grasshopper3d.com/group/ladybug/forum/topics/split-build...

Basically, I want to create a workflow to automatically subdivide a building mass envelope geometry into different floors which will be further subdivided as perimeter zones and core zones.

But I encountered an error for a particular building mass geometry (a quite regular form) which doesn't work with the split building mass component (see item 4&5 below):

The workflow is:

1. import building mass geometry:

2. divide the building mass into floors (one zone per floor) using one of the two different methods depending on whether the floor surface has holes or not:

3. use the split building mass component to further divide the zone for each floor into perimeter zones and core zone:

4. I tested several building forms which work for this workflow as shown below, except for one form C05 which is a courtyard block with small tower blocks on top of it:

5. in the last step, there is an error from the split building mass component saying that "solution exception: index out of range: 0" ...

So, I wonder if this is error is related to the split building mass component or related to the way the building mass geometry is created.

Appreciate your kind advice!

Thank you!

Views: 1605

Attachments:

Replies are closed for this discussion.

Replies to This Discussion

... if I change the input method to "Graft" for the _bldgMasses input node on the split building mass component for this form C05, the calculation will stop at zone 31 with the following errors:

Hello Grasshope,

I've noticed that the component will work if you change the height of the first contour point to a different value (0.5 in this case).

I couldn't figure out what actually causes the error, but this might work as a temporary solution.

M.

Thank you very much, Michael, for find out this little peculiar condition...!

... and I don't quite get why this parameter will make the workflow work, either...

Hi Grasshope


I tested your file. You used Honeybee_SplitBuildingMass nJAN_26_2016 in your workflow. If you try to use the latest version of it you'll see that the error message disappears, because there are two new lines inside the code that let you deal this issue. However, the results for that type of geometry will be something like this:

I think the issue is because of some curves in crvList.. and to solve it you have to play around the start number as Michael told you. 

Anyway, If you want, you can try the attached file where there is a method which should be fine for both geometries in your file: with holes or not.

The principle is to set the first number of the series component to half of height of floor (e.g. floor = 3 meters   =>   start = 1.5 meters) and you can create a piece of workflow to do this operation automatically.

Best

Antonello

here's the file

Best 

Antonello

Attachments:

Hello All,

Thank you for working through this issue together and I apologize for my messy code that tries to work around some of Rhino's deficiencies with solid operations.

Now that I have understood how complex this operation of splitting building masses is, I think that the best way of addressing issues like this is to break up this component in two: one component to split masses into floors and another component to split floors into core/perimeter zones.  With this organization, it will be easier to build up a library of functions that can divide floors into core/perimeter, which is the main function that is failing here.  I have put this on the to-do list:

https://github.com/mostaphaRoudsari/Honeybee/issues/497

Until I can get around to this or someone else takes on the challenge, you might have to play around with the component a bit (as yo have done Michael and Antonello) to get useful results.

I apologize I can't be more help for the time being.

-Chris

Dear Antonello and Chris, Thank you very much!

I'll follow the suggestions here to use the component on a "try on case-by-case basis".

As to the workflow suggested by Antonello, I found that the “offset distance of the cutting plane” as the quotient of the "height of floor" and the "denominator value" need to be carefully specified to avoid abnormal results in certain situations:

1. Antonello's workflow should produce result like this up to the component "boundary surfaces":

2. but in the following situations the result is not correct:

3. the source of issue might be that in these situations the cutting plane is overlapping with some of the horizontal surfaces of the geometry, creating boundary curves like B as shown below which will not generate correct floor surface for extrusion in later step:

Hope this helps in using Antonello's workflow.

Attachments:

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service