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…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
t taking part at the Object office in Poznań.
The intention of this event is to provide a relaxed and flexible tutoring experience, with only one goal – getting to know Grasshopper better. We will start with a very exhaustive introduction, then venture into the computational geometry world in whichever direction we like.
Schedule
The long duration of the series (with a possibility of extension) will enable each participant to come up with their own research problems during the learning process. The scope of those problems will have a major influence in setting the direction of each workshop. While a couple of initial meetings will be solely spend on Grasshopper basics, the latter part of the series will have a more open character.
Each meeting day starts at 10 AM and lasts till 5 PM, with an hour long break for lunch (14 hours of tutoring per meeting).
Planned meetings:
02/03 Dec | Intro_01.gh: user interface, geometry types, Rhino/GH connection
16/17 Dec | Intro_02.gh: data flow, paneling, geometry rationalization
06/07 Jan | Intro_03.gh: data I/O, excel, csv, data visualization, preparing geometry for fabrication
20/21 Jan | Intro_04.gh: working with complex definitions, project organization and helpful plugins
10/11 Feb | Intro_05.gh: looping with Anemone, generative design
17/18 Feb | Intro_06.gh: automating tasks with Anemone, scripting introduction
03/04 Mar | Intro_07.gh: scripting
17/18 Mar | Intro_08.gh: Kangaroo
14/15 Apr | Intro_09.gh: user_defined_1 (flexible)
28/29 Apr | Intro_10.gh: user_defined_2 (flexible)
…
ers of the last surface in the Brep, however, only the corners of the bounding box of the surface are generated)
It seems the rs.SurfacePoints only returens the control points of a surface rather than the actual corners of the surface. Can you advise if there's a way to do it?
Thank you!
Code:
import rhinoscriptsyntax as rsall_parts = rs.ExplodePolysurfaces(brep)centers = []vectors = []lines = []vertices = []cnt = 0for part in all_parts: center, err = rs.SurfaceAreaCentroid(part) centers.append(center) #rs.AddText(str(cnt), center) uv = rs.SurfaceClosestPoint(part, center) vector = rs.SurfaceNormal(part, uv) vectors.append(vector) N_start = center N_end = rs.VectorAdd(center, vector) line = rs.AddLine(N_start, N_end) lines.append(line) #vertices = rs.SurfacePoints(part) vertices = rs.SurfaceEditPoints(part) cnt +=1#C = centers#N = vectors#L = linesV = vertices#todo:#explore the surface methods in rhinoscript.surface...#import rhinoscript.surface.…
Added by Grasshope at 10:34pm on September 15, 2015
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
…
comerciales. Rhino permite comunicar ideas en el desarrollo, investigación, manufactura, marketing y proceso de construcción de un producto o espacio, antes de ser construido y genera documentos constructivos para la elaboración de los mismos. Permite exportar los archivos a las extensiones comerciales más utilizadas en la industria como DXF, DWG, Illustrator y 3ds entre muchos otros. La gran cantidad de extensiones suplen las necesidades especificas para arquitectura, diseño de producto, calzado, joyería, ingeniería, manufactura y visualización fotorealista.
Grasshopper es una extensión de Rhino que permite el modelado paramétrico sin tener conocimientos de programación o matemáticas avanzadas, facilitando el desarrollo de modelos de alta complejidad a partir de formas simples o complejas.
En este taller se cubren los principios de parametrización, analisis, panelización, Corte CNC.
Sesiones: 15 de 3 hrs
Duración: 45 horas
Días: lunes, miércoles y viernes
Horario: de 19:00 hrs a 22:00 hrs
Costo:
Pago único: $4,000 (antes del inicio del taller)
Pago fraccionado: $4,500
Primer pago: $2,000 para reservar tu lugar.
Segundo pago: $1,250 - 26 de septiembre
Tercer pago: $1,250 - 3 de octubre
…
if you can't resolve the details ... well ... they do that as well. For Europe contact my good friend Peter Stevens. (BirdAir).
In general: PRIOR designing ANYTHING (at all) you must formulate some kind of collaboration with a specialized manufacturer. Problem is that ... er ... if they don't know you they don't give much attention (this is a rather "closed" AEC sector).
On the other hand if your membrane is bespoke designing the components (anchor plates, masts, tensioners etc etc) and/or using bespoke ones available in the market (not many around. mind)... well ... this IS the core of the matter. Rhino is NOT suitable for that kind of stuff by any means.
Kangaroo 1/2 is the way to go when inside GH. Other apps especially the "pro" ones are very expensive. BirdAir has the best software for that matter but is mostly an internal product available as well only for few "strategic" partners as they call Architects who can design that kind of stuff.
Other than that have some fun:
Tensile Membranes test3 - Grasshopper
And this ... well ...is about NOT doing it:
Need help about using Kangaroo for form finding
…
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…
mations we use a STANDARD thingy (Plane.WorldXY) VS any other plane (that's what the Orient does). This applies for blocks/cats/dogs/anything: meaning that if anyone in the present or the future uses such a "component" he knows the origin (especially if other CAD apps are used in parallel).
2. NEVER EVER make a thing (i.e. the profile) to be oriented "off center" (in the occasion domain start/end values for x/y). If you want to do that treat the destination plane accordingly. That way you build up a mentality were the "source" is standard - so to speak.
3. RHS (but HEB/HEA/IPN/IPE blah, blah) fillets are related with thickness (in real-life) ... therefore when you offset (always inwards: meaning neg values for counter clock wise closed curves) ... take into consideration that simple fact.
…
r.
Jon has already done some very interesting stuff with regard decomposing matters using IFC schema (I'm not a strong admirer of any schema policy mind - for a variety of reasons).
Now the chaotic case:
1. This is deliberately fuzzy, faulty and chaotic in order to indicate the need (at least IMHO) for a next step with regard handling and visualizing (on a per individual data item basis, not on a per branch basis) data trees.
2. Why this Tree Manager future thing could boost GH up to an unseen level? Exploit the PDF attached - use Saved views and/or the Model Tree "decomposer" (file is greatly reduced in detail - only 1 out of 5 floors shown, no envelope stuff, stripped out of everything actually etc etc etc). Among a variety of things observe that there's transformations that are "selectively" applied whilst various components remain intact (in other words: invite existed "static" objects into the smart chaos) - this means that we need a far better control VS the series (of various type of data) that outline the solution of similar things.
3. What could/should do such a "visual" Tree Manager? Could he function within the existed "one Canvas for all things" environment? Do we need N "sub-canvas" (kinda the Views in any CAD app these days) to handle and visualize complex tree operations? Do we need control on a per data item basis? Do we need a re-mapper of a totally different kind? Do we need a Bake Manager? Do we need a Scenario (parameter combos stored etc) Manager?
Let's the debate begin
Best, Peter
…