Bake and re-reference a surface to decrease calculation times?

Disclaimer: although i am using the Elk Plugin, my issue is not elk related

Hi all, I am a 2nd year student in Australia. I am using elk on a project, to get accurate topography surrounding my site so that when i go to do renders i will get accurate distancing of mountains and the city in the distance, and the contours of the surrounding areas,

I have successfully imported into elk the relevant OSM and .tif data and can .

I am doing surface evaluation so i can look at the elevations and scale the topo surface to the osm data accurately. After this i will remap the curves [roads rivers etc] to the topography.

I have tried this on various computers, all with new i7s / i5s / xeons, all with about 32 gb ram. I can load and pan / view the roads and topography data without any problem. When i do a surface evaluation it takes about 15 mins to appear, and that is with only 10~ UV divisions on the topo surface. I have tried to turn everything off and turn things on as i need them, but still it wont load.

If i was to bake the topography into rhin [900 km2] and re reference the surface would it speed things up? Does grasshopper work faster if the information is exclusivley in grasshopper, or shared with rhino?

Or is there any other option, like convert it to mesh?

Or perhaps i am doing a surface evaluation the wrong way.

Any suggestions would help, i am only a second year student and they do not teach grasshopper here in this uni, i am teaching it to myself! :)

Ill upload the definition, the tif and map files are here in google-drive:

https://drive.google.com/drive/folders/0B-_OpLCeWqDSN2NmTWRIWDhzbzQ...

Note that i had as a last ditch attempt, tried to 'scale' down the all the geometry by 10 to see if it was simply the 'size' of the tiles in memory, so

Attachments:

toposimple.gh, 36 KB

Replies to This Discussion

Permalink Reply by arkadius belov on April 5, 2017 at 6:22pm

Hi Tom,

the need for grasshopper is that i am trying to learn how to use it. Also, i found the sketchup import terrain thing buggy. So as far as i know, ELK seems to be a good way to import OSM and topographical datas into a rhino model. I will of course like to make 2d lines and all the rest of it. Our site is 16ha, so i felt it important to try and do some topographical research, and model our structures over realistic ground, rather than flat surface [as all the other groups are doing]/ Sure, the use of grasshopper in this case far extends the assignment requirements, but again, the ELK plugin is a good way to import topos into rhino.

The topographical importation is no problem, it is the surface evaluation which is impossible.

So if you could clarify your answer, and perhaps provide a solution, it would help.

Are you saying that mesh will work faster?

Does anyone know any difference in terms of memory use, as to where the objects are held? in rhino or in gh?

Permalink Reply by Dharman Gersch on April 6, 2017 at 9:49am

I'm not quite sure exactly what you are trying to achieve, but I opened your file and i feel your frustration!

The OSM component is incredibly slow. Yes you should definitely bake something like this. then re-reference it into grasshopper (Use elefront -it's awesome!). I would even suggest all this geometry into its own rhino file and worksession it into your design or analysis files.

Note how the OSM component in my screencapture below took 4.1 minutes to run? None of the other components took anywhere near that. Grasshopper doesn't have any issue with this amount of information. re-referencing the curves back into Grasshopper takes about 22milliseconds..

if the delaunay mesh isn't smooth enough for your needs, use a mesh smoothing algorithm like Catmull-Clark from Weaverbird

Why do you need a surface?

See attached modified file

Attachments:

toposimple_Mesh_DG .gh, 17 KB

Permalink Reply by arkadius belov on April 6, 2017 at 7:29pm

Hi Dharman, thanks for your help, I will play around with the gh today and tonight, yes the OSM data is rather heavy, what i had to do was separate the OSM into component types so i could run it on my old laptop, and the new computers here at the uni still have a delay of a few minutes, I am very curious how you managed to trim the overhanging curves??, as i had gone to all this [amateurish] trouble of creating a bounding box from the topographical co-ordinates and intersect all the curves with this brep.

RSS