l console app that gets triggered after all the image tiles are exported and which will stitch them all together.
It runs outside the Rhino+Grasshopper process so it has at least 2GB of clean memory to operate in. If you're running on a 32-bit OS and the uncompressed image is larger than 2GB, this will still fail and you'll have to patch them by hand.
The intermediate images get written to the Temp directory, so they'll stick around until Windows deems them stale.
I also adjusted the bit-depth, if the output format is jpg or bmp then I use a 24 bits-per-pixel, png still uses 32 bits-per-pixel. Maybe this will solve the Photoshop loading problems. I cannot test this as my install of Photoshop consistently crashes on startup.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
d fly with a Porsche flat six).
2. Added a double (nested) Anemone thing (and the Mateusz version) and some comments.
3. Added a stupid "arm maker" cluster ... primitive/ugly/pointless - see one prototype attached about how to do it (you'll need a top feature driven CAD app for this - notice the Teflon low friction ring).
4. In order to "adapt" the cluster arm you need some "stretch" capability (orient, scale et all are the 1st step). Of course putting the cluster into the 2*loop is the art of pointless (Mateusz misinterpreted my bitter comments as regards the "slow" thing, I had absolutely no intension to recreate "live" the arm).
be the Force (the dark option) with you all.…
th a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).
3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).
4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).
5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).
6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.
best, Peter…
basis).
2. Rhino does not have a proper object display capability (objects per layer per view basis and/or per "collections" per view).
3. TSplines does NOT have any on-the-fly coordinate system definition capability (making "edit" a pointless waste of time). A small example about what this means as regards view navigation matters: imagine "hoovering" along a myriad of 3d objects: if you choose/opt for it: the moment that you touch an element (that could define a vector): this instantly becomes the working plane Z axis (very common capability in top MCAD apps). Not the same as a SpaceNavigator controller mind (far from it).
If these 3 were available > rebuilding anything with TSplines could be a joy (and very fast: about 2 minutes for your mesh)
Get this as well - Load Rhino file first attached in my previous reply (just for fun: not for your case, but we could do an extra WOW MERO spaceframe out of this paranoid M mesh).
BTW: Exo W is "tricky"…
ing the clipper code directly to GH2 so it is accessible natively.
Much better offset/inset curves! Added a 'Tolerance' slider... Fast! ~15+ seconds to open:
With '%Tool Diameter' set to 0.5 (50%) and 'Count' set to 100, time is ~1.5+ mins, though there are three distinct spot anomalies that need further examination...
…
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 …
gt; most probably > adios Amigos.
3. WP Loop VS ... > see above
4. Daniel VS ... > see above.
There's other dedicated apps for handling huge amount of data (using very fast ball pivot algorithms for dealing with the gazillion of points).…
Get plenty of RAM. Windows 32-bit can assign 2MB of Ram per process, so if you have lots of RAM, you can run Rhino+Grasshopper in memory all the way. I'd say get at least 4GB, and preferably 8GB. If you have a 64-bit machine, then it pays off to go even higher than that.
2) Get fast RAM. Memory access is the main bottleneck in many applications, so the faster the RAM the faster most apps will work.
3) Get a fast processor, rather than lots of slow processors. Only a few apps out there can truly use Multi-Threading (Rhino and Grasshopper cannot). These days, CPU manufacturers try and dress up multi-core CPUs as the next best thing. It is not. It is a lie. Until software can truly run on multiple cores there is no benefit to this. If rendering is a big part of your job, then it does pay off to have a multi-core machine though.
4) Get a good graphics card. I've always preferred NVidia over ATI, but there are many good ATI cards as well. You can go for a gaming card (they're cheaper), but note that these are optimised for drawing triangles. If you get a professional card, it will draw lines and curves much faster.
--
David Rutten
david@mcneel.com
Robert McNeel & Associates…
on) ... the only way to do something meaningful/realistic is to follow Bentley System's way: they had 3 rendering engines (all highly problematic and archaic), a bunch of highly paid "gurus" to "develop" the dead fish and an export to Maxwell capability as well (Maxwell is very slow and has no chance VS Nexus, see below). PS: "Gurus" had no idea about Quest3D and the likes.
At the time, I was near to some permanent ban (he he) from all Bentley Forums due to my acid writings about how stupid these methods were. In fact I openly proposed to Bentley (to Ray Bentley to be exact) to fire all "gurus" involved ... and follow the outsource path.
Finally Ray (he's very smart) did the right thing: after an agreement with Luxology ... now Microstation (the core product) uses the Nexus engine (as found in Modo). This means that the Nexus is fully integrated across the whole vertical suite of BIM AEC Bentley apps the likes of AECOSim (that includes Generative Components as well).
And as everyone knows THIS is the real McCoy (US movie industry is behind that thing).
Additionally Modo has the best GUI known to mankind (US movie ... blah blah) and astonishingly innovative thinking (US movie ... blah blah).
…