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.
…
You can create Design Options using the Iris Layer component!
For each set of geometries that you create, you can assign a layer and define whether it will be visible or not in Virtual Reality on the
Added by IrisVR to IrisVR at 8:34am on January 23, 2017
load path and what is a realistic and buildable structure vs one designed ad-hoc that looks cool.
No GH isn't geared to parametric constraint based modelling like CATIA. Then again, neither is CATIA a graphical algorithm. You are comparing apples with oranges.
Having used the CATIA API a lot, I understand the differences.
I disagree as regards the deployment of CATIA. It is very much still a "ivory tower" tool and the knowledge of its use in the AEC is very small and not shared widely. It will continue to do so until it becomes accessible to a wider audience much like rhino and GH. It has also stifled now for over 10 years, and with the release of V6, I don't see it ever catching up. The business model of rhino is better in that it encourages hobbyists to push the tool instead of waiting for a gargantuan software developer to make changes.
With constraint based parametric modelling and parametric modelling per se, the naming convention and ordering of data is key. I agree this is where more work is needed mote in GH.
Interesting job ad you shared, shows how little the person advertising understands parametric modelling. Understanding means nothing unless you have applied it.
To add, by work flow, what I implied is that we have an interoperable work flow to go form Excel to SAP to rhino to Tekla. All of that can potentially be set up on the canvas, on the fly, with the use of plug-ins. You cant do that with GC/CATIA or anything else. They don't provide a medium to define work flows.…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
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
…
mations we use a STANDARD thingy (Plane.WorldXY) VS any other plane (that's what the Orient does). This applies for blocks/cats/dogs/anything: meaning that if anyone in the present or the future uses such a "component" he knows the origin (especially if other CAD apps are used in parallel).
2. NEVER EVER make a thing (i.e. the profile) to be oriented "off center" (in the occasion domain start/end values for x/y). If you want to do that treat the destination plane accordingly. That way you build up a mentality were the "source" is standard - so to speak.
3. RHS (but HEB/HEA/IPN/IPE blah, blah) fillets are related with thickness (in real-life) ... therefore when you offset (always inwards: meaning neg values for counter clock wise closed curves) ... take into consideration that simple fact.
…
-life fabrication issues ... then ... well ... that's the reason for the Skype.
2. In general I would say that exploiting parametric "arrangements" (in the broad sense) is less than 5% of the whole ... given the fact that in real-life there's a lot of other constrains. Again using Kim's IKEA note: for instance packaging (at least for the magnitude of IKEA's business) is rather more important than ANY smart of stupid design.
3. Reliable components VS Design/Manufacturing cost IS the ultimate "fitness" challenge: this involves bottom-top design disciplines (not doable with Rhino/GH by any means) and ... well... some top dog feature driven MCAD app. Most makers/designers use the cheapo alternatives (SolidWorks/Creo etc etc) and the results ... well .. you get what you've paid for, he he.
4. Why bottom-top may you ask? (and what means this anyway?) Well ... one "connecting node" that would been made 1Z times at the minimum cost possible is a 100 times more challenging task than designing a shelve system that uses that node. See for instance A LOT of IKEA solutions (i.e. the nuts and bolts of them) that are exceptionally flimsy, very badly designed and ... well ... suitable for 1 week's usage (but there's some others that are less faulty). On the other hand IKEA actually serves the ephemeral ... thus ... this MAY be intentional (recycle > buy > recycle > buy > ...).
I buy therefor I exist.
For instance a certain IKEA mold injected "multi join node" for a given series of shelves ... it would sustain less than 5 minutes "abuse" (in case that someone would attempt to "rearrange" things). Moral: reality and theory ARE not the same thing.
I could continue until the end of Time listing "aspects" of the whole puzzle related with production issues ... but for the moment I would conclude by the following:
GH is a good "general" purpose graphic editor and Rhino IS NOT a feature driven solid modelling app. If you combine these 2 ... you can easily outline what you can and what you can't (or shouldn't) do on that subject.…