ion into the world of Parametric Design using these two sofwares. Grasshopper is a graphical program language through which one can model complex geometric forms. It builds generative algorithms were outputs to these forms are tied to the inputs of subsequent components. Rhino is an advanced NURBS modeler through which one does precision modelling, project workflow and organization. Grasshopper utilizes Rhino 3-D as a modeling platform to develop parametrically controlled models with real time geometric manipulation. These two programs are a powerful combination where Grasshopper parametrically defines the model logics to explore variations and optimized solutions while Rhino models and visualizes it. These two programs are essential for architects, designers, engineers, professionals, and students interested in exploring professionally the world of parametric design."This workshop will be held in Amman/Jordan between the 15th and 22nd of January 2016 from 5pm to 10pm …
his on the programming forum I'm guessing you're looking for a VB or C# approach to this?
Here are two algorithms (pseudo code, very similar) which will simulate a droplet of water on a surface (ignoring momentum, surface tension, surface angle, collisions with other drops etc.)
Algorithm one, easy implementation, slows down on horizontalish areas:
1) Pick a point somewhere on the surface. How you get to this level is your problem.
2) Lower the point by a certain fixed amount along the z-axis. Say, 0.1 units.
3) Project the lowered point back onto the BRep using a ClosestPoint function.
4) If the newly projected point is very similar to the input point, abort, otherwise, repeat step 2.
Algorithm two, more difficult, better control over step size:
1) Pick a point somewhere on the surface. How you get to this level is your problem.
2) Find the normal vector at this point.
3) If the normal vector is (nearly) straight up, abort.
4) Find the CrossProduct between the normal vector and the straight-up vector.
5) Rotate the normal vector 90 degrees around this cross-product.
6) Scale the rotated vector so it becomes the length of your sampling accuracy.
7) Move the point along the vector and pull it back onto the surface (should be a short distance if your step-size is small)
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:20pm on November 23, 2009
google's data (please correct if I'm wrong):
"SRTM1 data is sampled at one arcsecond (about 30 meters) and SRTM3 data is sampled at three arcseconds (about 90 meters). The higher resolution SRTM1 data is available for most of the US and the lower res SRTM3 data is available for most of the world."
The 3x3 stitching definition above is done in Rhino 4 but it doesn't actually "stitch together" or merge the surfaces into one. I had to do it manually in Rhino with the merge surfaces command. Which I think does a better job than grasshopper.
Also I think the calculations within it (distance of one degree change in lat/lng) won't be accurate enough (or high enough in resolution) even though they are correct so I cannot guarantee the 3x3 pieces are perfectly neighbouring sets of data (they might contain very very tiny strips of overlapped/missed topography data). However this error is really insignificant next to the limited resolution of the generated topography so it is neglectable if you're not a perfectionist like me.
Edit: For bigger areas Elk is much easier, but for smaller areas where you want to specify the area size Xiaoming's component is more convenient I think.…
s set up. All the goals in Kangaroo have indices identifying which of the points in the system they act on.
Assigning these indices automatically and still allowing inputs to change during simulation requires some tricks to work around the acyclic directed nature of Grasshopper.
In remeshing the indexing and even number of points changes which greatly complicates things if you want to also have goals assigned to certain edges/points.
Last time I spent serious time on this though was before the K2 library, so maybe time to revisit soon. I think it would probably over complicate things trying to accommodate this remeshing directly within the main Kangaroo solver component, but there could be a dedicated membranes tool (though I know you also want me to prioritize documenting the existing tools!).
Stepping back for a moment though - it is usually possible to separate the remeshing and relaxation into separate steps. Membrane relaxation generally needs well shaped triangles (no angles over 90), and remeshing can give you this. Of course the triangles change shape during relaxation, but if the unrelaxed geometry is not too dramatically different from the end result, and you use tangential smoothing to keep vertices from drifting, they can stay well shaped throughout. For bigger changes in geometry you could also remesh-relax-remesh-relax.…
Added by Daniel Piker at 10:29am on January 13, 2016
nds except only using CreateHBSrfs which can be unstable for me with some geometry (GH crashes).
If you want proof of the rotation not taking place using MSH2RAD, please look in the Daysim*.rad file that gets created when performing a Daysim simulation.
See example below. The same polygon is processed via the CreateHBSrs component and via the MSH2RAD component. The polygon gets rotated 90 degrees using CreateHBSrs but unfortunately not with MSH2RAD:
_______________
##GENERATED BY HONEYBEE
OPAQUE polygon b69a317a402d42c1994f410463cd_00 0 12 -15.824400 -5.615800 0.000000 -15.824400 -44.175400 0.000000 -15.824400 -44.175400 28.363100 -15.824400 -5.615800 28.363100
# SOURCE FILE: c:\ladybug\000000_TEST\SURR\MSH2RADFiles\SURR.rad
## c:\radiance\bin\\obj2rad -f c:\ladybug\000000_TEST\SURR\MSH2RADFiles\SURR.obj## OBJ file written by TurtlePyMesh
OPAQUE polygon object_1.10 0 12 44.175400 -15.824400 28.363100 5.615820 -15.824400 28.363100 5.615820 -15.824400 0.000000 44.175400 -15.824400 0.000000
_______________
All the best
-M…
what i want.
My intention is that the Randomly selected brick be rotated 90 degrees so that header face is proud of the actual wall face rather than stretcher face.
I can easily rotate the selected bricks and then protrude them in the desired direction. However, if i rotate the brick a gap is created on either side of rotated brick (refer sketch 1). I want to set a parameter that CLOSES THAT GAP, so that the wall remains watertight (refer sketch 2).
Brick size used 230mm (L) x 76mm(W) x 70mm(H).
Attached are
1) 1-Sketch: Explaining my conundrum
2) 2-Sketch: Explaining what i want to achieve
3) 3-Perspective: Baked Geometry of what i have achieved so far
Please feel free to ask for my GH definition if required.
I'm an absolute dummy in VB scripting.
So insight to solve my conundrum will be highly appreciated.
Cheers
…
if i select one by one and it shows
and also, select different amount of curves shows different angles[same curve]but the most important thing is all of them are wrong angles,
if i draw some 90 degree curve, the answer is right.
thank guys…
H are automated by using them as an ActiveX, the C# script object fails on the simplest tasks. That is, when initiating Rhino and GH externally (as by the following C# code):
Rhino5Application rhino_app = new Rhino5Application();
dynamic grasshopper = newRhino.rhino_app.GetPlugInObject("b45a29b1-4343-4035-989e-044e8580d9cf", "00000000-0000-0000-0000-000000000000") as dynamic;
The following very simple C# script component fails because it cant cast its input:
The c# code at the component is only:
Line 89 is simply casting of the input. Clearly, this makes the usage of C# component, under automation, impossible which is a major loss.
As said, when initiating Rhino and GH manually , all works well as in the following:
Any ideas why it misbehaves under automation (as an Active X ) ?
I added the gh file of this example.…
rection: there's no visible demand. Explanation: a lot of AEC oriented people (Smart Geo daydreamers) they think - potentially - about GH but they are rejecting it for more than obvious reasons: our job is 1% about the smart thing and 99% about the structured aspect of the smart (or stupid thing).
Back to that "hangar" : The primary role of this GH definition provided herein (and hopefully some future updates) is NOT to outline some academic solution (via some abstract collection of pipes/lines/points/surfaces) ...but to place in 3d space - properly structured - all the real-life (hmm, he he) bits that can compose the actual project. Of course if the bits could be parametrically driven assemblies ...well...you get the gist of the message.
All in all: I think that Engineers who are GH skeptics could see GH with a totally new perspective if, say, a collection of similar examples/test cases could be available for demo/evaluation/whatever > Ah! at last : this appears to be a real thing > what software did it? > say it again - Grass Components you said? > what sort of name is this? ... etc etc etc.
But since a similar development is quite expensive (and requires a team of several gurus), maybe this is rather a future potential task for the GH/Rhino people if they think that the AEC market segment could be beneficial for their products. Combine a similar capability with tools like yours and/or Evolute (planar quads are "a-la-mode" these days).
PS: forget trivial stuff > what about Stefanie? (plan B : better something than nothing)…