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
nd me to kill him but give him my regards anyway) is still around in BirdAir Italy ... talk with him.
3. Hope that you understand that designing the "details" means some decent MCAD app + FEA + this + that. "Fusing" this with some abstract graphic editor like GH ... is ... er ... impossible (in real-life, you know, he he ). Generative Components on the other hand may qualify but requires a lot of time in order to fully master it (approx 2-4 years).
4. FormFinder ... well ... that's utterly Academic but on the other hand ... (good luck).
http://www.formfinder.at/main/software/team/
5. http://tecno.upc.edu/cotens/software.htm
6. This is the second best (after the BirdAir internal stuff) but costs an arm and a leg
http://www.ndnsoftware.com/
7. This is a !%$!%$ in the !%$%!$:
http://www.sofistik.com/no_cache/loesungen/fem/leichte-tragwerke/
My realistic (low cost) advise:
use K1/2 (especially if you are after "parametric" exploitation(s)) ... and then diversify tasks: stuff for the structural department, stuff for whom claims that he can(?) design the "details" ... whilst be in a constant contact with the membrane provider (and in fact: the contractor for doing the real thing as well)
…
y to heaven (or hell) is full of pain,frustration and tears. In plain English: if you are not totally committed (and willing to pay the heavy price) ... well ... what about forgetting all that freaky stuff? (the best option, trust me)
Note: 99% of beginners dream to learn programing in order to make geometry. But the truth is that this is the least (and rather the most insignificant) that you can achieve especially when working in teams with lot's of CAD/MCAD apps (and verticals) in the practice of tomorrow (bad news: tomorrow is already yesterday).
Anyway: How to go to Hell in just 123 easy steps
Step 1: get the cookiesThe bible PlanA: C# In depth (Jon Skeet).The bible PlanB: C# Step by step (John Sharp).The bible PlanC: C# 5.0 (J/B Albahari) > my favoriteThe reference: C# Language specs ECMA-334The candidates:C# Fundamentals (Nakov/Kolev & Co)C# Head First (Stellman/Greene)C# Language (Jones)Step 2: read the cookies (computer OFF)Step 3: re-read the cookies (computer OFF)...
Step 122: re-read the cookies (computer OFF)Step 123: Open computer > burn computer > computers are a bad thing (not to mention the Skynet trivial thingy).May The Force (the Dark Option) be with you.
…
he two, including project information, materials, etc.
I'm looking at embedding Ecotect information within VB (or possibly C#) components and was looking for the most efficient connection.
It looks like I have 2 main options:
1. XML database-centric model of which both GH + ECO write to the XML document.
2. LUA scripting from within GH and ECO.
XML would be the first choice as it seeks to contain data purely outside of both apps, however, the redundant code that ECO needs to read / write gbXML files may be a headache to script the content.
Another question I had was to whether I can populate data (such as weather, location, materials, etc) directly from the Ecotect libraries (.lib) to feed into the GH components or would I need to decompile these first.…
of memory and can thus create far larger images then when it has to share memory space with an application like Rhino.
Combining images is not difficult if you know a bit of VB/C#, so I can help you out if you tell me exactly what you'd ideally need. Whether as a grasshopper script component or stand-alone app.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
er ... but ... Autodesk has other plans in mind.
Given the opportunity the main reason to use a solid modeller is ... well .. the fact that when you arrive in a polysurface (in a surface modeller) this signals the end of the road whilst in the solid apps it's just the beginning.
That said the best solid thingy out there is Siemens NX closely followed by CATIA (SolidEdge and SolidWorks are both owned by these 2).
The best way to get the gist of these things is to find some friend who (hopefully) knows his onions and ask for a 5 minutes demo.…
simple, there are many symetries in 3 main planes. So I used arcs rotated 45° from the main planes and I generate a pentagon which was mirrored and rotated many times.
At the end there are 24 pentagons and 8 hexagons so 32 faces, 54 points/vertex and 84 edges.
It could generate some others tessalation styles
…
ject that involves the design of an app that allows people to interact with a 3d model through some sliders.)
Ok, imagine you have a symmetrical shape like the one i drew:
What I intend to do is to have different 3 sliders that allow me to adjust the 3 distances (x, y, z) independently of one another.
-1st question: my idea is to draw the curves in rhino, then use the "divide" and "list item" components to extract the points I need. Is it correct? :D
-2nd question: the "move away from" component can be used in a symmetric way?
(I try to be more specific: with only one slider, can I move both points 5 and 6 simultaneously about the axis i drew?)
-3rd question: is there a way that allows the curves to reshape themselves as I move the slider related to the distance between a couple of points?
I hope I have been clear ;) I would greatly appreciate any help you can give me!
Matteo…
r.
Jon has already done some very interesting stuff with regard decomposing matters using IFC schema (I'm not a strong admirer of any schema policy mind - for a variety of reasons).
Now the chaotic case:
1. This is deliberately fuzzy, faulty and chaotic in order to indicate the need (at least IMHO) for a next step with regard handling and visualizing (on a per individual data item basis, not on a per branch basis) data trees.
2. Why this Tree Manager future thing could boost GH up to an unseen level? Exploit the PDF attached - use Saved views and/or the Model Tree "decomposer" (file is greatly reduced in detail - only 1 out of 5 floors shown, no envelope stuff, stripped out of everything actually etc etc etc). Among a variety of things observe that there's transformations that are "selectively" applied whilst various components remain intact (in other words: invite existed "static" objects into the smart chaos) - this means that we need a far better control VS the series (of various type of data) that outline the solution of similar things.
3. What could/should do such a "visual" Tree Manager? Could he function within the existed "one Canvas for all things" environment? Do we need N "sub-canvas" (kinda the Views in any CAD app these days) to handle and visualize complex tree operations? Do we need control on a per data item basis? Do we need a re-mapper of a totally different kind? Do we need a Bake Manager? Do we need a Scenario (parameter combos stored etc) Manager?
Let's the debate begin
Best, Peter
…