Grasshopper

algorithmic modeling for Rhino

Hi.

For a project I am working on I needed a way to calculate the amount of sun hitting a point on a building throughout a day. With this knowledge I can use a Genetic Algorithm to find the most suitable location for rooms, etc.

My project is written in C#, so I just needed the code and not the grasshopper plugin, but I tested it in Grasshopper and can share the plugin with you.

Here's a quick video demonstration of it:

I hope you find it useful.

Cheers,

Eirik

Views: 4274

Attachments:

Replies to This Discussion

Hi Eirik,

Nice plugin.

Is there a way to control the scale of the Fan you are getting? Sometimes you might need bigger distances to be covered/influenced.

Another one: Will be useful to input the hours range instead of the whole day.

Thanks,

-A.

Ver 0.2

 - I swapped the Brep.CreateSweep methods with the PerformSweep() method of the  Rhino.Geometry.SweepOneRail Class - and the script became 20-50 times quicker calculating Context intersections (because of a cleaner Brep there are less points to evaluate)

- Implemented the scale and time range suggestions from Abraham Yezioro.

Cheers, and thanks for your input.

Attachments:

Very nice.

Another suggestion: Could be useful to know the times the sun is unobstructed. Knowing how many minutes you have sun is OK, but knowing the times will be great.

-A.

antoher update.

Ver 0.3

- fixed minor bugs on context intersection

- added sunrise/sunset + blocked time of date

Attachments:

Hi Eirik,

First of all thanks for your work.

But ... now i'm getting confused. Some issues are appearing:

Please open the attached. You"ll see that no fan is created even though the location of the point is fine.

When i do succeed with the fan creation (most of the times) the blocked fan is flattened and located over the 0 height level. Is this what you intended to? If i may suggest, will be better to draw it with a different color (as you are doing), but with the real geometry and not flattened.

I believe there is a problem with the hours printed in the sunpath. They are hard to read but the numbers seem to be wrong for me.

Speaking about the hours, their input is not clear for your calculation component. I assume that the "starting hour" is pretty straight forward (but sometimes the sunpath disappears when i get to some hour). The "Time Range" is unclear. I suggest Start Hour and End Hour, so i know that if i want to see the fan from 10 am to 2 pm i'll give 10 and 14 (or something similar).

Hope i'm not bothering you too much.

-A.

Attachments:

Hi Abraham.

Thanks for your feedback. I'm a little busy with my master's thesis at the moment, but I'll look into it as soon as possible.

A couple of notes:

Try to shift the GMT slider on the top to +3 (for Haifa), that should give you more accurate times?

As this is part of a much larger genetic algorithm, I have made some choices for speed over accuracy.

The script generates the time for each 3 minute within the timeframe of the selected day. The sun vectors of these build the basis of the solar path on that day. Each minute would be more accurate, but also take longer to calculate.

My first idea was to intersect each sun vector with the surroundings. This would give me (with an accuracy of a minute/3 minutes accordingly) the excact time of the block. It would also mean that I had to potentiale check 60 * 14 = 840 for interactions with all context. So my approach was a bit different. I know the length of the solar path. I know the exact time of where this path starts/ends. So I approximate solarPathLength/minutes = length of a unit along the sun path. When I find a block, I check the length of the block and see how many minutes this would approximately be. As this is all math, it is very quick. But not super accurate. It gives me the indication I need though.

Cheers, Eirik

Hi Eirik,

Your approach sounds fine by all means. I don't know what are you trying to optimise, but in case it is related to energy consumption (for instance) i would suggest to add an "Accuracy" slider, so you, or any user can decide the "price" you or he, is willing to pay: Increase accuracy = increase time calculation. I would give 3-4 levels: Very accurate (1 minute), Close accuracy (3-5 minutes), Approximate accuracy (10-15 minutes), Rough accuracy (30 minutes), or something similar. It could be nice to compare results, so maybe for some situations you can be satisfied with the less accuracy ...

Interesting in any case.

Keep going and thanks,

-A.

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service