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 …
r visual programming tools in the games world. MS's Kodu, looks interesting. Kismet and Visual3d look even more interesting..... mainly because they are more 'interactive' or 'reactive', rather than DAG-based.
Seems like the evolution path for GH-similar apps is:
1. base 3d or CAD app based on C/C++ code.
2. Add scripting language interface
3. Add some kind of visual interface
4. Add graph sorting / propagation engine
5. Re-jig base 3d or CADD app to make managed/interpreted scripts run faster, multi-threaded.
6. Add dynamic typed language, DLR stuff
6. ....
6. Add constraints solver...?
7. Rebuild CAD display engine to be procedural at the GPU level?
Seems like there are available tools for converting scripts into some kind of flowchart. There are even visual debuggers. MS even has something called the 'Debugger Canvas'. Spreadsheet constraints.
Seems like the time is ripe for lots of new apps like GH.
…
lines, dedicated MCAD apps, BIM apps, team work AND elevators as well: if you design something "variable" and then attempt to service it via a "static way" (Revit) you'll discover that you are wasting your time. I can list you a lot of WOW towers that failed on that (elevator) matter ... but this wouldn't be polite for the designers: so let's continue.
2. The other critical thing is the system that does the skin: since "liquid" is the new WOW (it shouldn't) the task of "faceting" a facade and doing it with a system that doesn't leak (in the long term), doesn't pop the panels out of the frames and it doesn't cost the GNP of Nigeria ... well ... is not that simple.
3. It's a very common mistake for some future Architect to "skip" (even mentally) "trivial" matters like these ... but if you get used on this type of thinking you'll gonna pay a heavy price (as an Architect).
So my advise is: whilst you are after "form(s)" sketch frantically the nuts and bits of that form (not to mention ... er ... hmm... the elevators, he he).
best…
loop is a simple component
to iterate generative shapes with Grasshopper®
http://antonioturiello.blogspot.com/
RHINO OFFICIAL BLOG
FOOD4RHINO PROJECT
AEC-APPS.COM REVIEW