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…
, HVAC, blah blah).
BIM is NOT a parametric process at least having in mind graphical editors the likes of GH (or stuff the likes of Generative Components): it's a holistic data management approach. Some concepts used in BIM apps (for instance in AECOSim etc) the likes of "walls"/"openings" etc are "parametric" in the sense that allow auto perforation of this with that. On the other hand AECOSim is feature driven (since Microstation works in that "mode" as well) ... a thing that complex things even more with regard what is actually "parametric" and what not.
BIM is as good as the meta data structure is (especially the spec related aspect - Goggle MasterFormat and the likes). BIM AEC apps are notoriously incapable to work (without a lot of lines of code) with proper RDBMS. On the other hand Bentley Systems ProjectWise ... well ... but that's another animal (by no means a topic for the inexperienced).
In descending order or importance a contemporary AEC practice should use:
1. A general information "controller" like ProjectWise (who said/did what/when/why).
2. A Specs (say CSI - not the TV soap opera) management app.
3. Several Meta data RDBMS.
4. A BIM suite of apps.
5. Optionally some parametric thingy.
PS: For AEC ... when inviting the parametric thingy to the party you have only 2 options:
ProjectWise + AECOSim + Generative Ciomponents (my choice).
?? + Revit + Dynamo.
…
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)
…
uts.
If I change the number of polygon sides to 8 the result looks like this:
Note that there are no missing rows with 8 sides. I've tried all the numbers from 3 to 12 and in general an even-number of sides results in no missing rows, but an odd number of sides has a missing row. And for # sides 10 - 12 there are 2 missing rows.
I tried all the options for the Offset object's Corners variable which is use to make the solid outside wall, but this has no effect. I also tried rotating the cutouts a little and a lot, changing their size, height, etc., but this had no effect either. So I'm stuck on how to eliminate the missing row of cutouts.
I realize this is a more or less cosmetic problem (no one will see the bottom of the printed part unless they pick it up), but I'd like to get it fixed before I publish the final design. The attached GH file has all the components used to make these images.
…
Added by Birk Binnard at 11:58am on November 28, 2016
eries of ramps with slopes =< 10%.
Here's my pseudo-code:
1. Populate brep with random points
2. Sort points by Z values
3. Draw line from point '0' of sorted points to all other sorted points
4. Project lines down to plane of first point and cull all lines =< 5.7 degrees (10% slope)
5. Sort remaining lines by length and return line with the largest length (what I want)
6. Cull all points used to create lines =< 5.7 (step 4)
7. ??? now, I want to somehow pass remaining points from step 6 back into the loop and return the next curve that is: the largest length curve from all curves =< 5.7 degrees
I've attached the script
Thanks ya'll!
…
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
ose the radius of the terrain which will be taken into account around that location, and components automatically download and create the 3d terrain.
In order to use them, you would need to follow these steps:
1) go to http://www.food4rhino.com and register.
2) download the "ghpython.gha" file from this page: http://www.food4rhino.com/project/ghpython
Right click on that downloaded "ghpython.gha" and choose "Properties".
Click on the "Unblock" button, if one exists. Then click on "Ok".
If that kind of button does not exist, just click on "Ok".3) download the terrainGenerators.gh file I attached at the bottom of this reply, and open it in Grasshopper.4) you can directly use the first "Terrain Generator" component. For "Terrain Generator 2" components you need to download some other files and copy them. The component itself will provide instructions on how to do that. Here is a screenshot of the resulting terrain from the second component ("Terrain Generator 2"):
Both components may provide different 3d terrain geometry, due to different data sources.The first component (upper) will also provide satellite image of the terrain, which is a feature the second (lower) one does not have. You may get more help on this from the component author.Depending on the very purpose of your topography, Ladybug can further conduct a couple of terrain analysis of it.Let us know if you have any issues.…