priety software). Think Kangaroo with RON 100 fuel (add some nitrous oxide).
Back to domes.
1. Obviously you know the free WinDome Bono thing...but anyway get it (code included).
2. As I said on another thread (http://www.grasshopper3d.com/forum/topics/the-necessity-for-a-data-tree-manager) ... the big thing in AEC (because, for instance, nobody does domes for decoration/artistic stuff etc etc) is how to implement already designed things (see images above) within a smart stuff definition (or many).
3. Goes several steps beyond: these "breps" (to speak GH/Rhino language) are in most cases nested and some parts are "locked" for transformations some other not. That's the big thing when trying to outline real-life AEC solutions in the so called Smart applications. I think that this is not doable in Rhino since there's no way to edit (in place) a nested block.
4. Goes even further: for each custom made thing (truss nodes and the likes) ... there's a bill waiting. Meaning that the less customized a solution is (with regard industrial sourced existed parts) the more is possible for the client to sign the dotted line.
Best, Peter…
subsequently able to retain a higher level of flexibility.
In Rhino however a rectangle is defined as only a plane and two numeric intervals (one for x, one for y). The possible solutions to this would be:
Extend the Rhino SDK Rectangle3d type to include constant radius fillet corners. This can be done, but is a lot of work and will break the SDK.
Create a new type in Grasshopper which is smarter than Rectangle3d. This complicates developing for Grasshopper because now you have to keep two different types in mind whereas before only one was needed.
Remove the Fillet Radius input from Rectangle components. I like this solution because it results in cleaner, simpler code, but it does mean people may need to use two components where before one was sufficient.
Make the Rectangle type smart enough so that it can recognise filleted rectangles and undo the filleting. This is something I can do right now for Grasshopper 1.0 and it in all likelihood would not break actual existing files even though it is technically a behavioural change.
I'll try and get (4) done for Rhino 6 SR1, I might decide to do (3) for Grasshopper 2.0. I sincerely doubt that (1) will ever get done and I dislike (2).…
Added by David Rutten at 4:38am on November 6, 2017
t ... have a close look on these weird "slots" in the base mount plate - allow the struts to "follow" some base "auto" arrangement (up to a point).
2. After various ... er ... hmm... "communications" with a variety of apps.(some of them are not for public eyes) ...here's a concept demo about what could be done and fool the academics (that's the bit that I like the most)
In plain English (work in GH):
1. Create some wires that represent the struts and PAY attention on their limits of adjustability.
2. Create a nurbs curve through the points indicated with "balls" in the demo. Patch the nurbs.
3. Trim the nurbs surface with some "indicative" profiles OR use Kangaroo by applying a minimum possible relax state (if the latter add the rhomboid cables as well - they deform by pulling the membrane downwards).
4. Optionally put the real things in place (quite GPU taxing that one - do some Viz control).
best, Peter
…
need more code) AND in closed ones (see warnings).
2. The real stuff that I have in practice use solely C# code (even for Kangaroo2) and I have a strong feeling that this is not what you want (if you don't speak the language). It does that because GH is just a part (~10%) of the whole AEC arsenal (that is managed via C#) ... so everything must "fit" within the "general" production pipeline (code from some app "goes" to another with the fewer possible changes blah, blah).
So ... this attached could serve as an indicative guideline about the relaxation that Daniel does with his wonder thingy (Kangaroo, that is).
…
rella - Revit/AECOSim etc etc) then scripting is the only way to do business. In fact Dynamo/Generative Components would be your main parametric app ... but GH can offer a thing or two as well.
Other than that here's a very brief explanation upon the "steps":
1. Using connectivity trees (faces to edges, edges to faces, faces to faces) ...
2. ... Find the "internal" edges (meaning edges that are connected to more than ONE face) and store them in a tree. Doing this find the smallest edge as well (for defining the "module" of the pts divisions minus the start/end offset). Used an object type tree since I store the indices of the adjacent faces as well (an object type is a "general" container that can hold cats, dogs, numbers, bananas etc etc ... with the cost of un-boxing when an item is to be used [Note: un-boxing costs time but in this very simple case we can afford the "luxury"]).
NOTE: if you observe the paths on that tree you'll notice that they correspond 1:1 to the indices of the related edges in the EList List (of type Curve).
3. Loop withing the "interior" edges and define the coplanar vectors per edge related with the 2 adjacent faces. These vectors are the Cross Product (Google that) between the edge direction and the normal per face (at u/v: 0,0). Divide the edge (taking into account the start offset AND the ratio of the edge length/ minEdge [as derived from phase 2 as above]). Using these points create a "zing-zag" polyline and store it in the same path as the OEM edge.
NOTE: The polyline is not planar since each teeth is laying to the corresponding adjacent face plane (if the Brep Faces are not planar more "smart" stuff is required).
From this point (not included in V1):
4. Using Face to Edge connectivity data: IF a path exists (in the polyline tree as in 3 above) with the given index sample this polyline as Curve ... if not get the OEM Curve (case: "boundary"/perimeter Brep Faces). Join the Curves (take provision to report failures) and project them to the corresponding Brep Face plane (case: planar face) or ... to some suitable "mean" plane. Define a planar Brep out of the newly created closed planar Curve and extrude it (actually the Brep Face of it) both sides at once for doing a "solid". If Brep Faces are not planar ... well things are a bit more complicated (not nuclear science ... just another approach is required).
In fact ... is a bit more challenging than that since there's assembly tolerance AND clash issues around ... but this is the "general" idea anyway. …
hy? because instead of doing N*2 "cones", N balls and N rodes ... you should use instance definitions (blocks in plain English): ONE cone, ONE ball ... and unfortunately N rods (Rhino is not a feature driven CAD app, sorry). Complexity (and file size) increases "exponentially" if you want to mimic a real MERO system.
Recently a friend of mine send me (for inspection) a "big" canopy type of W MERO truss with 2300 nodes that was 500Mb (baked). After the "magic" treatment it become 1.2Mb (when baked).
Notify if you need such a C# based solution: (a) for solving any truss on any collection of surface Lists AND (b) putting "real" stuff (exact MERO members) on that (but is a "bit" complex).…
ime runs out, of unexplored planets. These masters of gravity risk their lives for the adrenaline, dodging gigantic rocks that could hit their ships crashing into planets and no hope that they can be rescued.
Requires Kangaroo and Human (and in full with Firefly).
Goal of the game
You have four minutes to get six stars and reach the goal. Or die trying.
If a satellite hits you, you will leave fired.
The game has three types of control
1 Using the keyboard (requires Firefly). 2 With an external device such as a smartphone or tablet (requires Firefly and TouchOSC app). 3 Using the mouse, from the grasshopper interface.
Download files
Gh, 3dm, touchosc and textures.
Video
http://www.grasshopper3d.com/video/space-riders…
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…
wich is nice actually :-) But I had 2 problems that make every thing just impossible to use : DIRECTION OF STEPS :
The motor can just reach one direction (for exemple clockwise) and when comes time to switch... not possible.
Details : When I put a value in HD.SM in V input, I put for exemple 100 with a slider so i have 100 steps and it works. Then I write 200, still working. and when I put a value that is less than the last higher value, for exemple 180 in my case the motor go endless to an higher amount, i mean 201,202,203...1000 etc... Dont undestand why :-/ SPEED : The speed is really really slow.
Details : The Firefly stepmotor component use the same library as heteroduino wich is Accelstepper.h but still going way faster. I tried lot of values in the S input (speed) but is not changing the speed that much, and sometimes its even changing the steps.
If there is another place where I have to post this, let me know also and I'll do it :-)
See you soon and hope some people are interested in the same problem ^^thanks :-)…