ay to make some real-life proper nodes for that kind of T truss (we use machined balls solely for MERO KK type of normal trusses).
3. I'll post here soon a modular demo system suitable for this case (real-life for AEC purposes - NOT for decorative/artistic stuff, I don't care about that since I'm an engineer). This would include a policy for the X struts that require a variable linkage (the X angle). and in the same time a multi cable tensioner "bracket".
4. "Basic" coding next week for T trusses ? Er ... well ... are you kidding me right? I mean that ... hmm ...
5. C# things (about 2+K) around me are classified into 2 "groups": things that are weapons in the right hands and others that serve as demos/start points for mostly abstract cases. The former are internal the latter for public use. I'll remove some sensitive lines from a T truss C# maker and I'll post it here as a "guideline" ... for ...hmm... 4.
All in all:
Provided that you have system(s) on hand (see 3) that work 100% OK in an ideal world you'll need:
A. Something that does the general topology AND (especially) clash detection. Maybe Kangaroo as well as a "first pass" with regard rigidity of the structure in case that you don't adopt a classic T "configuration" (there are many > Google tensegrity).
B. Connectivity trees that relate nodes/edges and maybe faces (say for roofing panels/curtain walls etc etc). Without them is impossible to assemble the T thingy.
C: Something that places real-life "parts" as instance definitions and/or (optional) a "tracking variants history" ability.
D. A bullet proof way to EXPORT things (on an assembly/component schema, say: STEP214 - see C) into a proper BIM app (the likes of AECOSim/Revit) and/or into a MCAD app (the likes of CATIA/NX).
E. FEA/FIM in order to validate the structural ability of the components and the T truss itself.
F. Roofing/cladding/envelope components.
G. "Interactive" cost estimation(s) - T trusses are hideously expensive at least versus "classic" trusses (exactly like a planar glazing system that retails 3++ times more than a humble semi-structural one)…
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.
…
s app NOR Rhino is a BIM thingy) I've decided to switch direction entirely: forget "bending" and concentrate on ways to have "some direct" (add some "" more) clue about wind forces.
V1 is a bit "basic" (no suction, not to mention the MIA remap force vector values thingy) : V2 does a lot of things more (and the test case is far more ... er ... "challenging": a twisted ultra ugly tower, what else? he he).
BTW: other than LBS "bending" ( pro-stuff for proper FEA SA apps: forget it) the most interesting thing is the air infiltration and water penetration min/max "suggested by building codes" values (a bit "elastic" in several countries) that ... are easily blown away if ... wind blows, that is. As Kim said: don't invest on cheapo curtain walls.
more soon …
loop is a simple component
to iterate generative shapes with Grasshopper®
http://antonioturiello.blogspot.com/
RHINO OFFICIAL BLOG
FOOD4RHINO PROJECT
AEC-APPS.COM REVIEW
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.…
UI - obvious if you recall who's developing MODO):
https://www.youtube.com/watch?v=A5Fd2jOgus4
https://www.youtube.com/watch?v=SkYwpyZNJcs
https://www.youtube.com/watch?v=pK3Q9BQSK4w
A small "bit" coming directly from the US movie industry:
https://www.youtube.com/watch?v=syZdi08_Sco&list=PLIHQjWXPloi_Q...
https://www.youtube.com/watch?v=kPj_Ey2IT9E
2. Trad AEC BIM apps (AECOSim - my favorite, Revit - no thanks, Allplan - no thanks) use RPC cells for similar tasks (an RPC cell is in fact a "DataTree" of images). In the past I did several figure animations (I'm not doing this any more: boring to the max):
http://help.archvision.com/products/bentley-microstation/getting-st...
3. Maya of course does everything (it's a unique amalgam of mesh and nurbs tools), but is totally unsuitable for AEC work.
https://www.youtube.com/watch?v=IVViMQHjjMw
So, assuming that you are in the AEC bandwagon, your options are:
a. AECOSim as the total "umbrella" for AEC matters.
b. MODO as the most innovative app out there.
c. Quest3D as the best VR app out there.…
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.…