tructures)
Bad news: real-life AEC trusses are far and away from lines.
Ugly news: Rhino is NOT an AEC app by any means nor it would ever be. For AEC app I mean the known 3 (Allplan, Revit and my favorite: AECOSim) and/or proper MCAD apps (like CATIA/NX). In plain English : without exporting (meaning (a) bake in nested blocks + (b) export via STEP) proper structured data (assembly/component) this WIP case is absolutely useless.
why may you ask.
well ... trusses are made with numerous shop drawings like this, that's why:
more soon.
best, Peter…
some weird engine, you know, he he) IS NOT like designing plain vanilla AEC things.
Therefore features/calculation methods/capabilities as found in MCAD apps (considered off topic by many in our trade) are mandatory for certain types of designs.
Anyway and if we forget FEA stuff, currently I have 3 C# goals:
(1) master the art of controlling the placement of existed blocks in GH defined topology(done),
(2) master the art of baking blocks(done) and
(3) master the art of baking heavily nested blocks that NX/Catia can understand (progress is slow).
…
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)…
nite a zillion of "solids" (closed polysurfaces in Rhino speech) you need a decent solid CAD app. Rhino is a surface modeller ... meaning that you should narrow your search towards the right girl.
3. Personally I work with Microstation (same 3d core engine as Siemens/NX [ParaSolids]) and CATIA/NX. The difference in speed for doing things like these ... well ... find a friend who works with any of these and experience it first hand. …
to run at full screen. I've gone as far as using an iPad to use as the second monitor via AirDisplay (which actually works really well) but have never been satisfied with any setup that required you to look back and forth as if at a tennis match all day long.
Not long after first using Grasshopper 3+ years ago I've had the desire for a "Live Viewport" component that would allow a live image of the 3d geometry being generated directly in the canvas. Every once in a while I search the forums with the hope of finding a solution, but always come up empty handed. Someday this might exist although for now I have found what might be the next best thing to a native "Live Viewport" component and its enabled with a small app named Sticky Previews. This app uses the task bar preview feature within Windows 7's aero interface to create custom, floating preview windows from any open window currently running. I've only just discovered the app, but it seems to do the trick and has been stable and problem free so far. -- I will post an update if I find out that I might have spoken too soon. The install allows for a 30 day trial and is $15 bucks to purchase. I just found the app and don't know anything about this group that created the app. If you happen to know of them, Id be curious to find out more.
divided windows, cramped and slow;
unified window with floating rhino model preview;
link to the apps webpage;
http://www.ntwind.com/software/sticky-previews.html
Also works with other apps;
and the about me page screen shot;
…
Added by Tyler Selby at 11:25pm on November 26, 2012
-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.…
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.…
it within the same smart umbrella? Or put it differently: is it worthy to exploit/consider/evaluate GH methods and development orientations that could "approximate" Utopia?
Let's split the case into segments:
The parametric part thing (although critical) is complex and rather beyond the scope of GH. Affects Rhino far more than GH. That said Microstation has 3 levels for doing this (but forget Microstation and/or Gen Comp).
So for a start we can focus in GH acting as a "composer" in 3D place of all the required (hopefully real) parts for the job. Parts must be nested AND readable as such by an external AEC app.
I'll post here (soon I do hope) all the parts that are required for assembling this. I mean individual static "blocks" that we assume (wrongly) that remain static: I mean we presuppose that the whole GH geometry is fixed (thus this is really a smart sketch of some sort) and no further changes are on schedule (that MAY affect parts).
That said I prefer an incomplete Utopia (one thing that "does" it all, or it thinks that does it) than a myriad of individual apps that take input one from the other and promise the Holly Grail (and/or delivering it). The core reason that I use Microstation as my basic platform is exactly that (obviously with a certain price to pay: bugs, shortcomings, wrong concepts in places etc etc etc).
Best, Peter
…
work in both versions. I've tested them in Rhino 5 and they work on my machine. If your screen looks like CarloMaria's, can you double check that all of the .gha files and .dll's have been unblocked. To do this, right-click on each of those files (included in the installation folder) and select Properties. On the pop-up menu, at the bottom of the page, you should see a button that says Unblock (this only appears if they are currently being blocked). For some reason, downloading files off the internet causes some of the files to get blocked... and Rhino 5.0 is more picky about loading them in that instance. Let me know if that helps. Also (and I found this out recently from another user)... it's better if you don't have both 32-bit and 64-bit versions installed on your machine at the same time. It seems that sometimes this can cause a conflict too. When the other user uninstalled the 64-bit version, everything loaded fine in the 32-bit application.
There' haven't been any major changes to the OSC components. I did add a couple of features mainly to parse up some of the messages sent from other applications... notably from GyrOSC (http://www.grasshopper3d.com/video/gyrosc-kangaroo). Some of the messages are sent as lists of 4 values (like the quaternions sent in that app) or lists of 9 values (like the matrices sent using that app). Anyway, other than adding datatype parsers for these, I didn't change anything else about the component... so it should work as before. Let me know if you're still having trouble.
Cheers,
Andy …