ple and/or easy.
I use GH/Rhino (really GH almost exclusively) for design. I find the parametric capabilities of GH simply spectacular. The Autocad apps are all quite good (and free) so I would have no problem recommending any of them. Meshmixer is a common starter for people new to 3D printing; it is targeted at more "free form"/artistic designs that is Tinkercad, which is more oriented for geometric/engineering/architectural designs. Sketchup is also a good place to start with 3D design; it used to be owned by Google but is now owned by a 3rd party company.
For slicers I've tried them all and have settled on Craftware. It's free and available at https://www.craftunique.com/craftware. For backup to that (it is still a beta product) I use Simplify3D (very seldom) but it costs $150.
If anyone cares I have uploaded an updated version of the Stepwell GH file; I tweaked it a bit to make it a little simpler and to make the base thicker so it would be more robust when printed. The dimensions of the part are large so it has to be scaled down to fit a particular printer. This is easily done with any slicer. The STL file from Rhino still has to be fixed; as exported it would print with no bottom - and I haven't figured out why that happens.…
Added by Birk Binnard at 12:36pm on February 14, 2016
logic in the script body. Now it works OK. Feeding all the right data required to Kangaroo is entirely trivial.
Happens now : create some "filters" about if a given cone is a classic one (suspended from a triad of high points == make triads of cables etc etc) or an inverted one (pulled from the ground == do something about that, anyway). This means find some interactive way to alter the cones data tree on a per branch basis (a slider access branches > the offset is altered > cone "type" > ...).
Just checked the P thing : it's all clear now (DeBrep).
That said I work in a smoke build on some MCAD app that does the following : when you hoover over a tool ... the underlying method is exposed and ... you can find what is where in nanoseconds.
Anders: I've looked at the Brep.Trim before posting this ... but .. well I can't get the gist of it (anyway the split loop did the job).
... If the Cutter is closed, then a connected component of the Brep that does not intersect the cutter is kept if and only if it is contained in the inside of cutter....
…
ee. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.
2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.
3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).
4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).
5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).…
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…
pending on registered students
Who is it for > Aimed to professionals or students in engineering, architecture, art, design (interior, industrial, product, jewelry, furniture...) and backgrounds related
Requirements > Zoom app and Rhino 6 or 7 for Windows or Mac.
Is previous knowledge in Grasshopper required?
It is expected students know the Grasshopper interface, connections, basic operations and transformations, simple data list structures: longest list, flatten, graft... We do recommend check the program of the course "Grasshopper Basics" HERE in order to make sure you have knowledge on these tools.
Dates April 9-10
Registration deadline Monday April 4
Schedule: Saturday and Sunday. 3,30 - 8,30pm
More info:
https://controlmad.com/eng/formacion/curso-grasshopper-intermedio/
…
y to heaven (or hell) is full of pain,frustration and tears. In plain English: if you are not totally committed (and willing to pay the heavy price) ... well ... what about forgetting all that freaky stuff? (the best option, trust me)
Note: 99% of beginners dream to learn programing in order to make geometry. But the truth is that this is the least (and rather the most insignificant) that you can achieve especially when working in teams with lot's of CAD/MCAD apps (and verticals) in the practice of tomorrow (bad news: tomorrow is already yesterday).
Anyway: How to go to Hell in just 123 easy steps
Step 1: get the cookiesThe bible PlanA: C# In depth (Jon Skeet).The bible PlanB: C# Step by step (John Sharp).The bible PlanC: C# 5.0 (J/B Albahari) > my favoriteThe reference: C# Language specs ECMA-334The candidates:C# Fundamentals (Nakov/Kolev & Co)C# Head First (Stellman/Greene)C# Language (Jones)Step 2: read the cookies (computer OFF)Step 3: re-read the cookies (computer OFF)...
Step 122: re-read the cookies (computer OFF)Step 123: Open computer > burn computer > computers are a bad thing (not to mention the Skynet trivial thingy).May The Force (the Dark Option) be with you.
…
hat aren’t completely there. BIM will have to continue to evolve some more if their supporters want to get to realize the promise that still is. I can’t say much about PLM, but I would say that both BIM and PLM should be considered in future developments of GH and Rhino. David has said several times that some GH limitations regarding geometry and data structures (central to interoperability) are actually Rhino limitations. So, I wouldn’t put so much pressure on David for this, or at least I would distribute the pressure also on the core Rhino development team.
Talking about Rhino vs. GH geometry, there is one (1) wish I have: support for extrusion geometry. GH already inputs extrusion elements from Rhino, but they are converted to breps. Is not a bad thing per se. The problem is when you need to bake several breps that make the Rhino file to weight several hundred MB. When these breps are actually prismatic, extrusion-like solids, is a shame that they aren’t stored as Rhino V5’s extrusion geometry in a file of just a couple of MB (I overcame this once with an inelegant RhinoScript that wasn’t good for other people). This was one of RhinoBIM’s main arguments. We can develop a structural model made of I-beams in GH using the Extrude components. We should be able to bake them as extrusions. That would also work for urban models with thousands of prismatic massing buildings (e.g. extruded footprints). Even GH’s boxes are baked as breps! Baking boxes as extrusions could be practical for voxelated or Minecraft-like models.
(2) Collaborative network support. Maybe with worksession handling, or something that aloud project team members to work on a single definition or in external references or something alike. I know there is another Rhino limitation on this, but maybe clusters are already going in that direction?
And maybe on the plug-ins domain:
(3) Remote control panel that could be really “remote”, like from other computer or device. There is an old Android App for that, but is not only a matter of updating. I mean, it would be great to control a slider with the accelerometer of an Android phone, but to have that on an iPhone will require another development team. If GH could support networks, a remote counterpart of a RCP plug-in could be developed as a cross-platform web app. I don’t know if you can access accelerometer functionality through HTML5 already, but for now, asking a client (or an spectator or any stakeholder for that matter) to control your sliders from gestures of his/her own phone would be awesome (maybe Firefly will fill that hole?).
(4) GIS support. GH already imports .shp files. Meerkat can even access the database, but what about writing to shapefiles or generating our own with databases processed/generated in GH?
(5) SketchUp support. Not only starchitects and corporations are using GH in the AEC. There are a lot of small firms, freelancers and students interested. Most of them use SketchUp for 3D modeling (not CATIA, neither Revit). Yes, you can import/export .skp from Rhino, but if GH could support nested block at bake time (also mentioned by others), it could write .skp files with complex relations of blocks (that are called components in SketchUp) and nested groups, going beyond what Rhino can export.
(6) Read/Write other formats. There are some challenges with proprietary formats that are not completely supported by Rhino, but they’re still a lot of open formats that are relevant to the fields of GH users, like stl and ply for 3D-printing. It could be nice to write mesh colors to a ply for 3D-printing a colored prototype based on GH colors. There are others, like IGES, STEP, COLLADA, etc. and 2D, like svg, odg and pdf. Some of them could offer special formatting options like custom data that the format supports but nobody uses just because is impractical to access this from direct modeling environments (but not from visual programming).
--Ernesto…
an almost planar tissue (your case) can cause a variety of issues up to the undo able state (metal parts/components grow in size as well for no reason). See forces estimated by FF below.
2. Therefor I strongly suggest to consider Plan B (a) mastermind a secondary "anchor" capability in order to achieve a far more stable system (b) use a mount design that can support this (and comply with the attractor concept of yours). Here's a variable mount custom system (mostly machined AND not cast) that is suitable for the scope (Rhino reads the stp file OK .... but makes a colossally big file - thus I attach here the original).
3. On first sight lot's of things in this system appear "odd". For instance: is it stable? Why these double cables are used? How far can be adjusted? (that's a classic case for feature driven parametric design - not doable with Rhino).
4. This concept (strut axis exported only) is tested in FORMFINDER and some other far more complex membrane apps that I use quite often (not RhinoMembrane). Here's is what FF tells us about:
Observe a different kind of "stress" when this is converted to radial type:
5. If you insert the stp file to the Rhino file provided (exactly as exported from FORMFINDER - no mods of mine of any kind) you'll see what goes where (and why). That way the usage of double cables is rather obvious (and a lot other things - for instance the way that the struts achieve "equilibrium", see the slots in the base mount plate.
6. If this approach is worth considering your definition requires some serious rethinking (far more simpler/manageable with the drawback that the real parts they are "static" they can adjust only as far this particular solution allows them to do - controlling them parametrically is clearly impossible with the current state of R/GH capabilities).`
All in all: this case works because the cables push the anchor points downwards and the struts push them upwards.
more in a while
…
ave the bytes available, they also need to be adjacent. All 4 frikkin trillion of them (assuming you need a million 1000x1000 pixel tiles). That's just not going to happen.
It could be that Photoshop has very clever memory management that allows it to store image data in non-consecutive chunks, but .NET does not allow this.
In fact this can be a real problem with much smaller images as well. In 32-bit Windows you're allowed 2GB of memory per application (sometimes 3). If Rhino+Grasshopper are already using up 1.5GB it's not like you can fit in an extra 0.5GB image before running into problems. Memory is almost never used in a consecutive fashion.
Rhino uses a clever memory manager (not the default Windows one) that results in less memory fragmentation and Grasshopper uses the .NET memory allocator and garbage collector which is capable of defragmenting memory usage. But even with these two optimizations memory fragmentation will occur (and the longer Rhino runs the worse it will get) making it less and less likely that you'll be able to find large consecutive areas of free memory.
The Grasshopper hi-res image exporter creates image tiles of 1000x1000 pixels and saves these files immediately. So it never requires more than 4MB while running. Once it's done making the images, it will start a different application that will stitch these images together. That's what the GrasshopperImageStitcher.exe in your screenshot is. Since this is a new app, it has 2GB of absolutely pristine memory to play with so it's a lot longer before it runs into problems. And when it does run into memory problems it won't bring down Rhino with it.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…