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).
…
ents instead of code ... it could yield a nightmare of components (and a myriad of parameters). For real-life designs I would never attempt to do this without code.
2. A certain experience with Kangaroo (or some min surf other thing since using K on these ... well may be the killing a mosquito with a bazooka thing). That said I'm a great admirer of Daniel's work. But on the other hand why not?
3. A "certain" experience with trusses/space frames.
4. A "certain" experience with instance definitions (that's not doable with GH components).
5. Years of experience with parametric feature driven MCAD apps - Image35 (NX/CATIA) for designing the real-life parts (that have NOTHING to do with "abstract" concepts).
In total I would say that a similar "app" with code (excluding the min surf/mesh thing) would require 6-10 full days of work (or even more).
BTW: https://www.google.com/url?q=http://www.grasshopper3d.com/forum/top...…
quite know where I'm going wrong. I can say that I have successfully put together a separate file which will send data directly to the Arduino (switch on a boolean toggle and watch an LED light up... how fun:) but receiving the data is a bit more complicated. For a long time, I was getting a continuous loop error, which would freeze my app. I've changed around the code (see attached file), but I'm still not receiving any data from my COM port (which I know is definitely working because I can turn on the Serial Monitor from the Arduino IDE and see the data coming in). I did have one question: Can you call different routines inside the script class (from Grasshopper), or do you have to always call the run script subroutine? If you guys have any suggestions I would greatly appreciate it. I understand it's a bit tricky to trouble shoot this issue since you may or may not have an Arduino handy to stream the data to your computer... but let me know if you see any glaring issues with the code.
Cheers,
Andy…
onstrates the following:
1. The definition's functionality employing HumanUI for the custom user interface.
2. Color based segmentation in manual and auto modes.
3. The evaluation of the definition's ability to handle different point cloud data sets.
This definition performs color based segmentation in two modes.
A manual mode, that implements the Delta-E CIE 2000 color difference formula, for targeted feature detection. An auto mode, that employs a simple RGB Color Range algorithm for quicker preliminary results.
RGB to XYZ to CIELab conversion and Delta-E scripts were based on Colormine's project code from github. Results have been compared and verified with the results of http://colormine.org/color-converter and http://colormine.org/delta-e-calculator/Cie2000.
Each stored class is charted and can be accessed through the UI, as shown at 2:30, where Delta-E CIE 2000, in CieLab color space, output results were found to be in perceptive conformity with human eyes, far superior to the preliminary RGB implementation.
Initial definition versions could process highly subsampled clouds in acceptable timings. Further research showed that employing the multithread processing of Volvox components, bundling the Delta E formula with the RGB to CIE lab color conversion script, per color segmentation calculations for a one million points point cloud would go down from 23 (c# script component) and 8 (vb script component) seconds to approx. 1 second (volvox script cloud component), thus allowing the segmentation of less subsampled point clouds.
I would like to thank Heumann A. and Zwierzycki M. who provided direct support with HumanUI and Volvox. Also Grasshopper3d forum users Maher S. and Segeren P., who contributed with Rhino viewport manipulation scripts.
More on Volvox:
http://papers.cumincad.org/cgi-bin/works/Show?_id=ecaade2016_171&sort=DEFAULT&search=ecaade%20volvox&hits=2629
http://www.food4rhino.com/app/volvox
http://duraark.eu/
HumanUI:
http://www.food4rhino.com/app/human-ui?page=1&ufh=&etx=
ColorMine:
https://github.com/THEjoezack/ColorMine…
tic systems and iterated function systems.
https://www.food4rhino.com/app/chimpanzee
https://matousstieber.wordpress.com/
#chimpanzee3d
I would appreciate any feedback, suggestions or reports of bugs. Please email me at matous.stieber@outlook.com.
To install:
Delete any previous versions of Chimpanzee you have installed
In Grasshopper, choose File > Special Folders > Components folder > Unblocked the files
Restart Rhino and Grasshopper
Chimpanzee changelog
Aug 31, 2019 - Chimpanzee 0.2.
Update to add 38 new components including hyperchaotic systems, maps and strange attractors. Additional features and options added including exponent input to Mandelbrot Set and Burning Ship.
Nov 11, 2018 - Chimpanzee 0.1
initial release
Further development may include Mandelbulb, Quaternion Julia Set, etc.
…
this, you'll have no horizontal force at the roller, but you will have it at the pinned support. If you wouldn't, then the structure will be displaced.
Usually, in 2 dimensional structures, if you want to know if an articulated structure is isostatic (as opposed to hyperstatic, which is what you have right now) is to use the following formula:
b+c-2·n=0;
b being the number of bars, c the number of constraints you have and n the number of nodes. In your case: b=19, c=3 (displacements constrained in X, Z at your pinned support and only constrained in Z at your roller support) and n=11, so: 19+3-2·11=0.
I recommend you to download the app SW Truss, as it's very useful to check your results instantly.…
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.
…
dro). The quality of the driver is also critical: hard to imagine NVidia working overnight to fix "some" driver bugs due to requests from gamers. Game cards are notoriously bad in dual monitor configurations.
3. A zillion of cores (triumph of marketing VS common sense) divided by the given clock rate ... gives you just ONE poor old core (Rhino/gh are single-threaded apps) that tries to do the job.
4. Single Xeon E5 2xxx V3 (the higher the clock the LESS the cores = better) would be my recommendation. ECC fast memory is also a must.
PS: Find a friend who operates a "loaded" H/P Z840 and test your defs.
…
OSC are just simple horizontal sliders.
The problem I'm facing is that additional toggle items in OSC, which write only 0 or 1, don't get through properly. They do without problems as long as the timer on the FireFly is off. I also can write to the OSC app via gHowl to turn LEDs on or off.
As soon the FireFly timer is back on the toggle get lost in 8 of 10 attempts. The sliders still get through correct.
Any idea if this is because of a timing problem between gHowl and FireFly? I played around with different GH timer settings but that didn’t change much.
Cheers,
Peter…