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
Tags:
Replies are closed for this discussion.
Hi Antonello,
Not really. Initially I've planned to use only the _origin point and its elevation (the central point from the "Terrain Generator 2" component) for visibility analysis. So basically the visibility would always be calculated starting from that point (that's the photo on the left, below).
But you have just discovered a new way of choosing a custom point! Thank you for that! (that's the photo on the right):
By the way, the Visibility legend coloring scheme in "Terrain analysis" component had a bug, which is visible on the last photo you attached. I waited for us to settle the origins input/output name before fixing it. The newest version of Terrain analysis has it fixed. I also added text to _terrain, _origin, and _elevation docstrings suggesting the usage of "Terrain Generator" component data as well.
Also, try setting the "refine" input to "True". It will increase the quality of the final analysedTerrain mesh.
Once again, thank you Antonello for the useful support and collaboration!
That's a very useful feature Antonello!!
Keep up the great work!
Hello Antonello and Djordje,
First thank you very much for your two super useful components!
I used to have the same workflow as Djordje's component using opentopography data but written with "ugly" "basic" Grasshopper and PythonGh script. So I am super happy to have this new TerrainGenerator2 component added to Ladybug suite ! :)
However, following the install instructions and checking for the opentopography.org availability, the component does not seem to manage to download the data... (see picture attached).
Djordje, do you have any idea about what I can I do or check to fix this?
Other question, just to be sure, regarding the "origin_", is it the central point that you to get out of the output mesh/surface? And does it need to be the point at the actual point elevation or does it need to be the point projected on the ground floor (as I do in my definition)?
Thanks again for your work,
Cheers
Hi Aymeric,
Thank you for the kind words.
I opened a new topic in here, to answer your questions.
Best regards to lovely Réunion.
Hi Saket,
There's an update to the component you're using. Can you please update the same? The update date is Jan 12 2017. I hit this error once and re-running the solver solved it.
-Devang
Can you share the file?
Although didn't make any changes in the example file but still, if you want to have a look.
On a side note it works on my personal laptop.
Welcome to
Grasshopper
© 2024 Created by Scott Davidson. Powered by