Grasshopper

algorithmic modeling for Rhino

Hi All,


During these days I have written a new component called LB terrain generator.
I have studied a bit GEO components of gHowl and Google's API.
And I read that there are some limitations when you use Google's API, especially if you'd like to achieve a great quantity of data without overloading Google's servers.

I used a way to request data without overloading Google's servers by using a tiling method. Obviously, this component respects the limit of 2500 requests per day.

This is how the component works:

1) set one point and its coordinates

2) generate surfaces by using isotrim component (Basically, each sub-surface is a request)

3) set the number of division of each surface and the resolution of Google static maps

4) run, move points and generate surfaces with surface from points

5) apply textures to the surfaces

In the image below another small example:

I was thinking that this should be useful for wind simulation with Butterfly, maybe.

 

Best

Antonello

Views: 6492

Replies are closed for this discussion.

Replies to This Discussion

Hi djordje and Chris,

firstly, thanks for the links and information.
Djordje, I have modified Terrain Generator, I used an input like yours - radius - in this way should be easy to make a terrain model. However I just use rectangular surfaces.

I have followed your advice about the surfaces, and after a couple of tests I saw that meshes should be better, especially when you have big differences of elevation within small zones.

LB terrain generator is not fast but is accurate enough. I'll send a pull request for this new version soon.

Best
Antonello

Hi Antonello,

I like the new radius input !

Indeed meshes are the best representation of the terrain, that's why I used both meshes and surfaces as outputs.

When surface is interpolated through a grid of points it may slightly deform (buldge) due to nurbs tendency to create a smooth surface. Mesh terrain on the other hand will be always be a bit more precise representation of the raster from which it has been created, as it will be consisted of a series of independent faces made from the grid of points.

Btw, you do not have to use the "Delaunay mesh" component.
You can create a rectangular mesh by calling the Ladybug meshFromPoints method:

import scriptcontext as sc

lb_meshpreparation = sc.sticky["ladybug_Mesh"]()
terrainMesh = lb_meshpreparation.meshFromPoints(numberOfPtsIn_vDirection, numberOfPtsIn_uDirection, pts)

Hi djordje,

Thanks. I have added terrain Mesh output to LB terrain generator, you can find an example file on Hydra.

If you want and if you are interested you could do a couple of tests to compare the two components. I suggest you don't go over 2000 meters of radius, you shouldn't have crash problem but it could require lots of time (minutes).

Best
Antonello

Great!!
Keep up the good work!

Hi djordje and Chris,


I have changed the component, I have added the possibility to connect locations directly. This can help you understand where the EPW locations are.

or


Furthermore, I have written a new small component, Ladybug_Location Finder. This component let you generate locations by typing the address of the location.

Best

Antonello

Nice. I like the new icon as well!

Amazing stuff, Antonello!

This is going to make us so much less dependent upon the EPW for solar position data.

Feel free to send a pull request whenever you think its good to go!

This is very nice! Is it already added to Ladybug?

Mostapha,

Yes, I merged everything in the other day.  It's all in the WIP section at the moment.

Hi Mostapha, Chris and djordje,

Please, let me know if LB Location Finder works fine. It requires a secure connection because of one of the Google's API.

This is a small test where I used chinese and korean characters.

Best

Antonello

Hi Antonello,

My apology for taking me too long to reply.
I couldn't test your component on my PC due to it not supporting the System.Net.WebClient class.
I tested your component on my friend's PC tonight, and it worked great!
I can already see some of the nice benefits of its usage. With the Google Earth component, you made a quite a remarkable addition to the Ladybug set of components! Keep up this great work!


Just as a mention: I am attaching a screenshot of two new components:
The first one: "Terrain analysis" performs a couple of terrain analysis types, and the second one: "Flow paths" performing the water flow analysis.
Screenshot example of both is given below:

It would be nice if your Terrain Generator component could benefit from using these two new ones.
In order to do that, Terrain Generator would have to output the terrain in a form of surface as well. My modest advice would be to add the "type_" input, which will determine whether the "terrain" output is a mesh, or a surface. This will make it consistent with Terrain Generator 2 component.
To create the terrain surface from a grid of points, use the NurbsSurface.CreateThroughPoints method:

import Rhino as rc

uDegree = vDegree = 3
uClosed = vClosed = False
terrainSurface = rc.Geometry.NurbsSurface.CreateThroughPoints(pts, numberOfPtsIn_vDirection, numberOfPtsIn_uDirection, uDegree, vDegree, uClosed, vClosed)

Of course this is just a suggestion, I am not imposing anything.

Attachments:

Hi djordje,

amazing stuff! Thanks for your advice. I have modified LB Terrain Generator to try your components.

I have changed _geometry and _terrain from "ghdoc object" into "No type hint" in order to use your components because my terrain surfaces weren't recognized.


As you can see from the images, the analysis results are amazing. Great work!

I'm going to send a pull request today ;) in this way you could find how to manage terrain imput of LB Terrain Generator in the checking phase.

Best

Antonello

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service