iew mode:
instead of the fabrication mode (individual Breps ready for 3d printing - minus "some" little details with regard their effortless connection > this is what V3 does):
2. GH does not (AFAIK) include the mesh.Offset capability (used a little C# for that).
3. I promise to translate the test C# used into native components ... if the result is what you are after (you never know, he he).
4. Rounding (fillet) the thickened panel lips (around the hole and with regard perimeter panels) is doable but only via code: AFAIK GH does not include the Surface.CreateRollingBallFillet method (something that does fillets, that is - forget it for the moment). In fact ... there's a complex way to do it without that method ... but is not for the moment (next week you'll be 100% more experienced, he he).…
that greatly facilitates "impossible" tasks of the past).
Anyway..
1. Graft means get a List and make a Tree thus the sweep has profiles (as items in tree branches, i.e. Lists) VS rails as ... er ... we need to match apples to apples here: for each branch that has profiles get a branch with a single item (the rail).
2. In general without fully understanding the way that GH manages "nested" collections (DataTrees) is utterly frustrating to attempt anything. Spend some time on that matter. Some fellas would advise you to learn "on the way". I would strongly advise the opposite: first understand what a piston is and then design a machine.
3. Rules et all ... well you can do some stuff via components but the things that I have in mind require code not because is far more "efficient" in complex data structures (a matter of personal preference that one) but mostly for controlling items in collections on a per item basis (don't ask what this means, he he) tracking history, using hierarchies of instance definitions (blocks), controlling sliders, controlling events ... and many other ultra freaky things.
4. Coding is the next step towards the Holly Grail. Requires serious commitment, time and guarantees frustration, agony, and pain until ... you arrive into a point where all things appear "easy" (kinda like attempting a double forward in windsurfing: easy provided that there's "some" scars around). …
on 2: I think the reason to draw a fitness landscape is to highlight graphically the presence of local minima, even in a simple optimisation problem. In architectural terms, this means getting an idea of how many sub-optimal solutions there are in a problem, which helps while exploring conceptual design proposals.
Have a look at this very basic example (which I published with two colleagues on "Shell Structures for Architecture", chapter 18): a shell footbridge (24m x 4m footprint), which is generated by two parabolic section curves (the two apex heights are the two design variables). The maximum displacement of the structure under gravity load and self-weight is the objective function. Simple example, but several local minima and interesting shell forms (image below).
@AB,
The expression used by David in the Number of Samples Input is a simple “x+1”. By grafting the Divide Curve Output, he got 81*81 lenghts (6,561 values). You have to make sure that number is divisible by the no. of samples. The second expression used for the Length output is only a scaling factor (my guess), to control the height of the fitness landscape drawing.
Cheers…
would actually be to parametrize the dome itself. Otherwise, turning the 3D lines into a sorted list of grouped points is going to be a huge mess, and we are not even sure if the CAD model would have some kind of internal order to start with...
2.- Anyway, if you want to do it the 'hard' way (choosing each point independently, totally not recommended...), you should first find the 'base panel' to perform sun angle calculations, and then modify the top geometry proportionally to this angle:
3.- If you'd rather instead work with opening variables holes on it, the procedure would be very similar, but instead of modifying the geometry, drawing the circle and the resulting surface:
See files attached.
Good luck!…
icosecond laser. In their wisdom the manufacturers of the laser have paired a cutting edge laser with an ancient CNC. The machine requires straight cut lines only (it doesn't handle curves) so these have to be converted from the original design, for which I'm using Grasshopper. Also, it requires multiple passes at a slight offset each time in order to ablate the silver successfully, generated again using Grasshopper.
So far so good. The machine controller is very picky about the format of Gcode it accepts, and it will only accept Gcode. So I am currently exporting the Grasshopper processed design as a dxf and running it through a dxf2gcode converter. This must then be manually processed (I use vi!) to change x references to c, y references to d and remove any references to z. Precision must be to 3 decimal places.
Silkworm is of course ideal for creating Gcode but is pretty specifically written for 3D printing I think? How configurable would it be with the config file to produce what I've described above, even if it's raw gcode which could then be wrapped manually with a header and footer? I'm thinking you'd have to rewrite portions of the module which is of course a bit pointless for such a specific task. Thought I'd ask anyway!
Cheers,
Simon
…
nal vector.(see pic 1)
Second: Holding an abstract mesh or surface with a 3D grid structure. Basically creating 90 degree vectors on an uneven surface coming out of the object, sort of like a cactus with a grid pattern. (see Pic 2)
Third: I think #1 answers this issue: when the lines hitting the rough surface go in two different grid directions, their intersecting points are too close together. Structurally these points can be united and the vectors would be reduced. Manually deleting these lines after being baked is currently the only option. It would be so cool if there was a mathematical arrangement that would connect points that are within a certain distance to one another. (see pic 3)
…
ry close to the screen (the model unit equivalent of a pixel deep). I am using the DrawForeground override to generate these objects...everything is fine, except that we'd also really like the users to be able to output high quality images directly from the viewport. Using the ViewPortCapture (either to file or clipboard) with higher scales can create some excellent images...but here's where we run into trouble.
The geometry that is created close to the screen through the Display Conduit tiles along with the resolution in the output image...so even though the rest of the model geometry scales up, the HUD geometry stays the same resolution but gets repeated in a grid (2x2 at 2 scale, 3x3 at 3 scale, etc.). What is interesting is any geometry created in the normal model space (say, a circle at the WorldXY) gets rendered correctly. I have also tried using the CalculateBoundingBox override, using bounding boxes for the objects drawn, but it doesn't seem to help.
I have picked up on a discussion over at the McNeel forums, but haven't gotten any guidance over there, and was curious if anyone here had any pointers.
thanks!…
Added by David Stasiuk at 3:31pm on November 24, 2015
o use these extensions in order to integrate numerous tools for analysis and simulation in the architectural process.
This course aims to develop a link between the virtual and the real context model through structural or environmental simulations, using other software or plug-ins dedicated. Through this link the virtual model receives physical properties that can further modify and adapt the initial model. This creates feedback loops that can optimize the design to provide an object responsive to environmental conditions.
Curriculum
Mesh subdivision with Weaverbird, continuous surfaces without NURBS
Genetic optimization with Galapagos, optimal search
Physical environment feedback with Diva and Geco, solar and day lighting analysis
Adding physical properties with Kangaroo Physics, interactive form-finding
Linking the parametric model with structural analysis using Karamba, structural performance simulation
Extracting data with Firefly and Kinect, 3D scanning and human movement tracking
Exchange of information between Grasshopper and other applications with Ghowl links to internet feeds or Excel files.
Schedule:
Module 04 / Grasshopper intermediate & advanced (24 h)
11 Oct – 26 Oct 2013
Fri:
Sat:
16-20
10-14
Language: Romanian
Organized by:
OAR Bucureşti – Romanian Order of Architects, Bucharest Branch
Trainers:
Ionuț Anton, idz arhitectura (ART-Authorised Rhino Trainer)
Daniela Tănase, idz arhitectura (ART-Authorised Rhino Trainer)
https://www.facebook.com/cursurigrasshopperrhinoceros
http://www.oar-bucuresti.ro/anunturi/2013/02/27/d/…
Added by Dana Tanase at 2:49am on September 5, 2013
2013 | Sábados 19 y 26 de octubre. 15 Hrs.
Horario: 9:00 - 18:00 Hrs.
Instructores por BIO|Architecture Studio: A design & building laboratory.
Palabras clave:
Diseño Computacional, Scripting, Rhinoceros 5.0 + Grasshopper, Parametrización, Análisis, Fabricación Digital, 3D print.
Para mayor información:
MArch. Kathrin Schröter. E-mail: kschroter@itesm.mx
Dirección de Arquitectura. Oficinas de Aulas 1, segundo piso.
Carretera Lago de Guadalupe Km.3.5 Col. Margarita Maza de Juarez, Atizapan de Zaragoza. | 5864 55 55 Ext.5750.…