the contours they show are all generated from 3 arc second SRTM files, even if in the United States where higher resolution data is available from 1 arc second. Also the contours are likely 2D in their map since. Granted, their contours may look nicer, but I think it's just because they're processing the HGT file with the GDAL Contour app to generate a Shapefile.
That being said, starting last year the USGS started releasing 1 arc second SRTM data for the rest of the world outside of the US. It's not the friendliest website, but I've been accessing it from here (be warned it will probably take a few minutes to load). You could download the appropriate tile and use the SRTM Topo component and get better looking resolution than you've seen with the 3 arc second data.
There's also the possibility you could do the same thing OSM is doing, but with the higher resolution data. Download the GDAL library and run the gdal_contour.exe file on the 1 arc second HGT file and you'll get a shapefile with all the contours. Elk doesn't directly work with shape files, but you could use Meerkat GIS to import the shapefile. I've only done a few quick tests, but I've had trouble with the scaling with this method, both using Meerkat and using Autodesk's Map3d to read the shapefile, so perhaps it's my inexperience with gdal_contour. It also looks like it's making the 1°x1° tile's square instead of scaling the X values as it goes farther from the equator. Nothing that's insurmountable, but still you should watch out for it.
Regards,
-Tim
…
lly at each branch keeping the same data structure than the original one (like the exercise attached), but in a fashion that this data manipulation can be sorted out with less manual input (like having an unique cluster to handle this data ideally), since this logic wont work if new "fruits" are added into the cart =) i.e. watermelons and oranges!
Apps I used in this exercise: Anemone, Wombat
Thanks for your time!
Alan
…
basis).
2. Rhino does not have a proper object display capability (objects per layer per view basis and/or per "collections" per view).
3. TSplines does NOT have any on-the-fly coordinate system definition capability (making "edit" a pointless waste of time). A small example about what this means as regards view navigation matters: imagine "hoovering" along a myriad of 3d objects: if you choose/opt for it: the moment that you touch an element (that could define a vector): this instantly becomes the working plane Z axis (very common capability in top MCAD apps). Not the same as a SpaceNavigator controller mind (far from it).
If these 3 were available > rebuilding anything with TSplines could be a joy (and very fast: about 2 minutes for your mesh)
Get this as well - Load Rhino file first attached in my previous reply (just for fun: not for your case, but we could do an extra WOW MERO spaceframe out of this paranoid M mesh).
BTW: Exo W is "tricky"…
a black hexagonal background. They are containers of parameters but parameters in themselves, like the "x" in a mathematical function. So, what I do is something like:
2) That depends exclusively on the panel, not the cluster. Then you can't. It is also not possible to assign access (item, list, tree) to the parameters.What you are trying to do, assigning components to the inputs directly, can only be done from code or using snippets. http://www.food4rhino.com/app/brick-box…
glass panel).
2. This actually means that the parts on duty they don't differ that much. Meaning that we can use an "average" size (and "local" topology) acting as the Jack for all trades.
3. Meaning that we can effectively solve the abstract topology with an abstract app the likes of GH and then place in properly defined coordinate systems all the real-life bits and nuts ... closely "emulating" a pro solution (that could "adjust" the parts as well).
4. This means that one particular C# needs more lines of code since as it is it defines cable axis on a per nod to node basis ... but in fact these are defined as the min segment between curves (circles to be exact).
5. Additionally the end part of each strut differs depending on how many pairs of stabilizing cables are used (either 2 or 1). Meaning some lines of code more for defining the proper coordinate systems for the instance definitions.
6. This is the reason that I've postponed mailing to you the 4 horsemen (because PRIOR finishing the whole you MUST define what parts to use: the classic bottom-top design approach).
But in order to receive the Salvation (aka: Apocalypse) you MUST answer correctly to a simple puzzle:
Provided that money is no object, pick your car:
1. Ferrari 245 (Less is more)
2. Lancia Stratos (Lethal).
3. Cobra 427 (Men only)
4. Ford GT40 (Mama mia)
5. Ariel Atom (Mental)
6. Aston Zagato GTB4 (Sweet Jesus)
7. Fulvia HF Fanalone (THE racer)
8. Lambo Miura (Enough said)
9. Lotus Elise (Just add lightness)
10. Alfa Romeo 8C Competizione (In red)…
Please mail me the file that is causing problems so I can debug it.
Regarding your quad-core, Rhino and Grasshopper are not multi-threaded applications. (Very few apps actually are). Therefore I can only use 1 of your cores which equals about 25% of a quad-core machine.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 4:07am on November 10, 2009
dro). The quality of the driver is also critical: hard to imagine NVidia working overnight to fix "some" driver bugs due to requests from gamers. Game cards are notoriously bad in dual monitor configurations.
3. A zillion of cores (triumph of marketing VS common sense) divided by the given clock rate ... gives you just ONE poor old core (Rhino/gh are single-threaded apps) that tries to do the job.
4. Single Xeon E5 2xxx V3 (the higher the clock the LESS the cores = better) would be my recommendation. ECC fast memory is also a must.
PS: Find a friend who operates a "loaded" H/P Z840 and test your defs.
…
Get plenty of RAM. Windows 32-bit can assign 2MB of Ram per process, so if you have lots of RAM, you can run Rhino+Grasshopper in memory all the way. I'd say get at least 4GB, and preferably 8GB. If you have a 64-bit machine, then it pays off to go even higher than that.
2) Get fast RAM. Memory access is the main bottleneck in many applications, so the faster the RAM the faster most apps will work.
3) Get a fast processor, rather than lots of slow processors. Only a few apps out there can truly use Multi-Threading (Rhino and Grasshopper cannot). These days, CPU manufacturers try and dress up multi-core CPUs as the next best thing. It is not. It is a lie. Until software can truly run on multiple cores there is no benefit to this. If rendering is a big part of your job, then it does pay off to have a multi-core machine though.
4) Get a good graphics card. I've always preferred NVidia over ATI, but there are many good ATI cards as well. You can go for a gaming card (they're cheaper), but note that these are optimised for drawing triangles. If you get a professional card, it will draw lines and curves much faster.
--
David Rutten
david@mcneel.com
Robert McNeel & Associates…
ents instead of code ... it could yield a nightmare of components (and a myriad of parameters). For real-life designs I would never attempt to do this without code.
2. A certain experience with Kangaroo (or some min surf other thing since using K on these ... well may be the killing a mosquito with a bazooka thing). That said I'm a great admirer of Daniel's work. But on the other hand why not?
3. A "certain" experience with trusses/space frames.
4. A "certain" experience with instance definitions (that's not doable with GH components).
5. Years of experience with parametric feature driven MCAD apps - Image35 (NX/CATIA) for designing the real-life parts (that have NOTHING to do with "abstract" concepts).
In total I would say that a similar "app" with code (excluding the min surf/mesh thing) would require 6-10 full days of work (or even more).
BTW: https://www.google.com/url?q=http://www.grasshopper3d.com/forum/top...…