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...…
th a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).
3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).
4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).
5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).
6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.
best, Peter…
y, he he) on that market segment (trusses and the likes) ... well ... you can't do anything in real-life without code. Too many reasons to list them here (indicative: connectivity Trees, member clash detection, instance definitions, managing solution variations talking to MCAD apps that do the parts in real-life ... blah, blah). If this is just an abstract exercise ... forget all the above.
3. Using a // (to the ground) "inner" surface (the 2 edges, that is) is tricky because without code you can't be sure where the whole procedure failed (a red component means nothing).
4. The weird big "component" provides ways to do things with surfaces (most notably: rebuild) that are not available as native components. Rebuild is critical when dividing surfaces
have fun, best, Lord of Darkness…
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
…
r this or that etc etc).
3. I would strongly advise to use some decent feature/dimension driven CAD app in order to create families of concrete deck/beam(s) profiles "manually" (the good old way PLUS recording history and using parameters for the steps taken). Find a friend who knows, say, AECOSim and ask for a small demo on that matter (specifically ask what DDD is [Dimension Driven Design]). Then you can have these in Rhino/GH, define some topology, do the "solid" and if 1M of decks/beams are required rather use instance definitions and plane to plane transformations (that's what the Orient component does) instead of creating 1M clone objects.…
discussions during this period.
The major topics discussed for GH2 during this period will be:
Documentation/Help
GHA/Cluster/VB/C# App-Store
Localization (i.e. languages other than English)
Constraint Engine implementation
Improved VB/C#/Python development tools
Multi-threading the solver
Building a Mac version
If you feel something important was left out, please let us know here. Note that incremental improvements and bug-fixes are not worth discussion as we'll try and get around to them no matter what. Topics on this list have to fit the "Are we going to try and do X?" format.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:07am on October 11, 2013
n splitting curves and then join them to create the region; but I'am looking for a more straightforward solutions. 3- I know some plugins like clipper could do this, but I'm looking for more flexible solutions.
4- I tried Brep[] CreatePlanarBreps(IEnumerable<Curve>) in ghpython, but it doesn't work.
…
onstrates the following:
1. The definition's functionality employing HumanUI for the custom user interface.
2. Color based segmentation in manual and auto modes.
3. The evaluation of the definition's ability to handle different point cloud data sets.
This definition performs color based segmentation in two modes.
A manual mode, that implements the Delta-E CIE 2000 color difference formula, for targeted feature detection. An auto mode, that employs a simple RGB Color Range algorithm for quicker preliminary results.
RGB to XYZ to CIELab conversion and Delta-E scripts were based on Colormine's project code from github. Results have been compared and verified with the results of http://colormine.org/color-converter and http://colormine.org/delta-e-calculator/Cie2000.
Each stored class is charted and can be accessed through the UI, as shown at 2:30, where Delta-E CIE 2000, in CieLab color space, output results were found to be in perceptive conformity with human eyes, far superior to the preliminary RGB implementation.
Initial definition versions could process highly subsampled clouds in acceptable timings. Further research showed that employing the multithread processing of Volvox components, bundling the Delta E formula with the RGB to CIE lab color conversion script, per color segmentation calculations for a one million points point cloud would go down from 23 (c# script component) and 8 (vb script component) seconds to approx. 1 second (volvox script cloud component), thus allowing the segmentation of less subsampled point clouds.
I would like to thank Heumann A. and Zwierzycki M. who provided direct support with HumanUI and Volvox. Also Grasshopper3d forum users Maher S. and Segeren P., who contributed with Rhino viewport manipulation scripts.
More on Volvox:
http://papers.cumincad.org/cgi-bin/works/Show?_id=ecaade2016_171&sort=DEFAULT&search=ecaade%20volvox&hits=2629
http://www.food4rhino.com/app/volvox
http://duraark.eu/
HumanUI:
http://www.food4rhino.com/app/human-ui?page=1&ufh=&etx=
ColorMine:
https://github.com/THEjoezack/ColorMine…
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)…