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...…
exploran los principios básicos de Grasshopper en Rhino 5 para desarrollar algoritmos de superficies responsivas a datos generados por dispositivos y aplicaciones como: iPhone/iPad/iPod, Android, GPS, Kinect, etc.
Es necesario traer tu Laptop con Rhino y Grasshopper instalados.
Rhino: http://download.rhino3d.com/rhino/4.0/ev aluation/download/
Grasshopper: http://download.rhino3d.com/Grasshopper/ 1.0/wip/download/
Cupo Limitado
info@dimensiontallerdigital.com
$4,000.00…
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…
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.…
first appeared in software like maya I believe where there are options for the translations (move, scale, rotate) called discrete move, discrete scale, and discrete rotate. This meaning you can only move, scale, or rotate them by specified interval values.
"Are there non discrete vectors and polylines" A single vector is of course discrete. The discrete we refer to in the image above is about discretisation across the collection of vectors forming a polyline. A polyline is discrete after it is made. This discrete is about the process of making that polyline. Telling the polyline to be "x" amount of angles only in advance.
Vectors and lines are already discrete in segments when compared to curves yes, but not in angle as there is an infinite possible number of angles in a world axis (continuous). There is no control over how many angles. A curve might subdivide into 100 angles when converting into a polyline in which case it may not be as useful for the construction of some joints or bends, say you wanted only 1 joint type then you would force the polyline to only have 30 degree angels with discrete vectors (of course this wont follow the curve as close but will be more optimized from a fabrication or bending standpoint) Consider these as more discrete - discrete lines (discrete in segmentation and angle). Rather than a polyline having infinite possible angles to represent a curve - these can have a pre-determined amount of angles - in the case of this image it looks like there are only 14 possible directions the line can move. As for the fillet, that is just after the fact - the important thing is how the original lines were generated.
Think of it a bit like AutoCad's Tracking settings that lock you into drawing at specific angles.
Anyway check out the plug-in here and I am sure you will understand as soon as you open the example files: http://www.food4rhino.com/app/discrete-vectors…
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.
…