GH works (b) creating feature driven very complex parametric parts manually (the trad way) ... and then combining them in assemblies derived from (a) with components derived from (b).
Exactly what Generative Components does (if we forget the bugs, the extremely slow response, the lack of any development, the bugs, the bugs and finally the bugs).
Creating collections (libraries) of components in Rhino it's pointless since he doesn't support feature driven modeling. This means constrained driven geometry (solids NOT surfaces - another reason for totally excluding Rhino for the scope) that describe the actual components (that belong to nested assemblies etc etc).
So back to (a) : The only thing that Rhino/GH can do (in real-life) is to outline an abstract topology with "basic/primitive" geometry in place (= lines in this case). Exactly what this WIP script does, in fact. Of course it can do calculations as well (clash detection AND drilling axis related stuff).
But never say never: let's inspect an example from some WIP project (AECOSim + Generative Components) of mine to see what can GH/Rhino additionally do (in real-life):
Imagine a rigid "ring" (the truss shown) that manages tensional forces (via cables) in a "ring like" formed tensile membrane combo. Membranes (inverse cones) pull the ring thing downwards and mast attached cables pull it upwards = equilibrium (or disaster if some cable fails, he he).
So assume that the abstract layout (lines, that is) is made with a similar GH script with the one posted here. Rhino can't even imagine doing the parametric fasteners shown - thus we exclude them from the equation.
But GH could(?) "indirectly" feed a proper CAD app (from AECOSim to CATIA) with "seed" information in order to help making the components and the assemblies of components.
For instance assume that every truss linear member is a classic MERO system (ball - sleeve - cone - tube -cone -sleeve - ball). It's pointless to create (in GH) and bake a nested Block structure with "real geometry" (surfaces, that is) and export it via STEP : we can export lines + coordinate systems instead (ACS) ... that could be sufficient for AECOSim to replace "parts containing lines + ACS" with real-life "parts containing constrained/feature driven solid objects".
So the real challenge here is to mastermind a suitable nested block structure (and an equivalent GH_structure) that could pass the right assembly/component info.
I'll be back soon with some add-on script that takes truss lines and makes them MERO style "surfaces" in order to practically outline the issue(s) and the goal.
…
... er ... hmm ... I would strongly suggest Plan B:
How to get the gist of C# in just 123 (+1) easy steps (I've already posted that 3-4 times if memory serves well):
Step 0: get rid of the computer (press the OFF button), buy some cigars:
Step 1: get the cookies
The bible PlanA: C# In depth (Jon Skeet).
The bible PlanB: C# Step by step (John Sharp).
The bible PlanC: C# 5.0/6.0 (J/B Albahari) > my favorite
The reference: C# Language specs ECMA-334
The 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 120: re-read the cookies (computer OFF)
Step 121: tun ON computer
Step 122: do something
Step 123: shut down computer permanently, forget all that
May The Force (the Dark Option) be with you.…
vate Sub RunScript(ByVal x As Object, ByVal y As Object, ByVal z As Object, ByRef A As Object, ByRef B As Object)
Dim c_list As New list(Of nurbscurve)
Dim P_list As New list(Of Point3d)
For i As int32 = 0 To z
Dim c As New Ellipse(plane.WorldXY, i / 2, i)
Dim g As New NurbsCurve(c.ToNurbsCurve)
g.rotate(y * i, New vector3d(0, 1, 0), New point3d(x, 0, 0))
c_list.add(g)
Dim e As New BoundingBox
e = g.getboundingbox(False)
p_list.add(e.Center)
Next
Dim polyline As New polyline(p_list)
a = c_list
b = polyline
End Sub
To do the same thing is more easy in the old version
because i can't get the center of an ellipse directly
how can i do ???
thanks
ceason
…
Loft is connecting circles on her\his arbitrary way, not counting the wireframe wich is made from Crvs from points.
Like a wireframe in a picture with a last def. from you, such exact Surface I need. Maybe some sweep rail, where a every 2 circles are Rail and a arc (trough 3 point) or segment of interCrv is a section Curves.
At the endeffekt I want to accomplished a worm like a nest, something like a worm city, where people will live in a worms , to create microclima inside ( In direction of B. Fullers dome), it term that one ring(segment) of each worm is a place for 50 or more habitants. Prox. Pro worm 250-500 habitants.
My steps are:
To make a Srf’s from accomplished wireframe.
Then evaluate this surface with Ecotect (that is why I am still using GH 0.6 because of Uto’s plugin for 0.6 and 0.7). And I also have a Rhino 0.4 Sr6
Make a sun reacting facade or pneumocells.
Make a def. to assign a GH def. on multiply Crv’s. For this I need also evaluate a Crv’s length, because of subdivisions number. If I assign the same divisions number to all Crv’s , the longest and the shortest will be divided at same div. Num.! What we don’t see in a nature.
Make a living space inside of worm, with vertical farming, residents, parks etc.... Dividing a worm Srf’s on separated rings (segments) , to count their area. Bigger ring will have a more people and so on...
Make a model :)
I hope that I don’t sound too much pretentious :)…
um in Microstation):
But let's stay in Rhino for the shake of the thread...:
..the tricky bit is to use in GH a set of "static" geometry and instead of exploiting (at infinitum) forms, shapes, and such ...just finish the difficult part of the story:
1. Assume that this is covered the classic way: corrugated sheets + Foamglas T4 + fasteners directly glued on Foamglas (avoid classic fastener penetration = leaks) + aluminum guides + some MV Zink sheets (or CalZip or copper or titanium).
http://www.foamglas.ae/building/en/downloads/
2. The catch in such type of roofing is to make a "smart" definition (GH or Gen Comp) that can deploy these sheets into the existing geometry taking into account (a) their maximum flex/bending capability - trying to create a "skin sphere" instead of a faceted ugly chaos (b) their physical size in order to avoid getting into the usual wedge situations (i.e: examine if a given flexible sheet of metal - kind of ribbon- can cover a NURBS of some sort).
In other words and in the broad sense of things: how we can inquire static geometry in GH and get back, say for a start, a collection of working planes in order...etc etc etc. Or how we can use Orient brep type of components in Rhino geometry?
…
UI - obvious if you recall who's developing MODO):
https://www.youtube.com/watch?v=A5Fd2jOgus4
https://www.youtube.com/watch?v=SkYwpyZNJcs
https://www.youtube.com/watch?v=pK3Q9BQSK4w
A small "bit" coming directly from the US movie industry:
https://www.youtube.com/watch?v=syZdi08_Sco&list=PLIHQjWXPloi_Q...
https://www.youtube.com/watch?v=kPj_Ey2IT9E
2. Trad AEC BIM apps (AECOSim - my favorite, Revit - no thanks, Allplan - no thanks) use RPC cells for similar tasks (an RPC cell is in fact a "DataTree" of images). In the past I did several figure animations (I'm not doing this any more: boring to the max):
http://help.archvision.com/products/bentley-microstation/getting-st...
3. Maya of course does everything (it's a unique amalgam of mesh and nurbs tools), but is totally unsuitable for AEC work.
https://www.youtube.com/watch?v=IVViMQHjjMw
So, assuming that you are in the AEC bandwagon, your options are:
a. AECOSim as the total "umbrella" for AEC matters.
b. MODO as the most innovative app out there.
c. Quest3D as the best VR app out there.…
x way). Why may you ask? Well ... in order to control what "module" (triangle) is where my dear Watson, that's why.
2. Your data set is wrong in the sense that you provide a single dimension list of already "ready" Breps (triangles) and then instruct the C# ... er ... to subdivide each triangle (that's like dating 123,45 girls at once: not recommended unless you are some Sheik of some sort).
3. There's several solutions to that problem:
3a: The right way is to subdivide a surface AND THEN individually modify any desired module BEFORE the C# continues post processing the modules. Any why this is a bit complex? (although achievable) Well .. the explanation is ... er ... complex, he he (GH is not designed for doing this: GH operates in a fire and forget mode, so to speak, as regards collections of things).
3b: The other way is to mastermind some (rather inefficient) way to influence modules BEFORE the C# continues ... blah blah. In plain English: using the so called attractors and the likes (I dislike that: I'm an engineer and that's not engineering by any means, but is OK for artists).
3c: The other way is to create a Plan B in the C# : don't subdivide > just get these things (as Lists/DataTrees of Breps) and compute things/whatever/US (not the land of free). But ... we need to supply the modules in an U/V indexed way (obviously we can do that automatically with "some" lines of code more - but is a very stupid way to address the issue).
PS: a DataTree IS NOT a List of List of List of ... it's an indexed collection of single dimension Lists.
best, Peter…
Albahari) > my favorite
The reference: C# Language specs ECMA-334
The 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 121: open computer
Step 122: get the 30 steps to heaven (i.e. hell)
Step 123: shut down computer > change planet
May The Force (the Dark Option) be with you.
…
hes or surfaces on this: it's the nature/topology of your design that dictates that approach):
This C# only (as usual) collection of scripts works in 2 phases:
Phase A: Gets points in 3d space (NOT internalized in order to alter them manually) and creates a mesh. Depending of your search distance (actually: radius) the mesh is variable. If you bypass phase A (feed the 2nd C# with some other mesh of yours) then the mesh is triangulated automatically.
Phase B: Gets the mesh and creates your "tri-breps" in a DataTree where first dimension branches are indexed as the mesh faces (Note: "tri-breps" are not joined to a closed brep for speed).
PS: An auxiliary 3rd C# gives you an indication about the size of mesh edges in order to enter proper offset (where offset means offset of the tri-mesh edges) values.
PS: If you overdone with values > faces are excluded (and the equivalent tri-breps are NOT created):
PS: if you enter possible/doable offsets > all faces play ball:
best, Peter (Load Rhino file first)
…