ption file on this page (http://livecomponents-ny.com/2012/04/01/study-voronoi-relaxation/) to essentially create a triangulated frame from 3d voronoi points (ignoring the kangaroo part for now).
I'm stuck on the point where (..I think..) I'm trying to define a function that will offset a line to triangulate the previous offset. I've included an image of the component I'm stuck on as well as the original description jpg.
At this point I have no idea what I'm doing and if I've made any previous mistakes, any and all thought/ideas/help would be greatly appreciated!
Thanks a heap in advanced :)
MakingtheTriangularSectionFrame.PNG
MinimalSurface-TriangularSectionFrame-from3DVoronoi.gh
OriginalTutorial_3d-voronoi.jpg…
rtitions." (http://wias-berlin.de/software/index.jsp?id=TetGen&lang=1)
To continue with my wrapping career, TetRhino (or Tetrino) is a .NET wrapper for the well-known and pretty amazing TetGen mesh tetrahedralization program. It provides one new GH component for discretizing or remeshing objects using TetGen. Basic tetrahedralization functionality is exposed with a few different output types that can be controlled. At the moment, the only control for tetrahedra sizes is the minimum ratio, which is controlled by a slider. This is hardcoded to always be above 1.0-1.1, as it is very easy to generate a LOT of data (and crash)...
The libs are divided again into different modules to allow flexibility and fun with or without Rhino and GH, so have fun. All 4 libs should be placed in a folder (maybe called 'tetgen') in your GH libraries folder. Remember to unblock.
Once again, the libs are provided as-is, with no guarantee of support for now, as I use them internally and do not intend to develop this into a shiny, polished plug-in. If there is enough interest, I can tidy up the code-base and upload it somewhere if someone more savvy than me wants to play.
TetgenGH.gha - Grasshopper assembly which adds the 'Tetrahedralize' component to Mesh -> Triangulation.
TetgenRC.dll - RhinoCommon interface to the Tetgen wrapper.
TetgenSharp.dll - dotNET wrapper for Tetgen.
TetgenWrapper.dll - Actual wrapper for Tetgen.
Obviously, credit where credit is due for this excellent and tiny piece of software:
"The development of TetGen is executed at the Weierstrass Institute for Applied Analysis and Stochastics in the research group of Numerical Mathematics and Scientific Computing." See http://wias-berlin.de/software/index.jsp?id=TetGen&lang=1 for more details about TetGen.
To wrap up, some notes about the inputs:
These are the possible integer Flags (F) values and resultant outputs for the GH component:
0 - Output M yields a closed boundary mesh. Useful for simply remeshing your input mesh.
1 - Output M yields a list of tetra meshes.
2 - Output I yields a DataTree of tetra indices, grouped in lists of 4. Output P yields a list of points to which the tetra indices correspond.
3 - Output I yields a DataTree of edge indices, grouped in lists of 2. Output P yields a list of points to which the edge indices correspond. Useful for lots of things, very easy to create lines from this to plug into K2 or something for some ropey FEA (or not so ropey!) ;)
As this component can potentially create a LOT of data, especially with dense meshes, care should be taken with the MinRatio (R) input. This will try to constrain the tetra to be more or less elongated, which also means that the lower this value gets, the more tetra need to be added to satisfy this constraint. Start with very high values and lower them until satisfactory.
Hopefully shouldn't be an issue, but it's possible that you need the 2015 Microsoft C++ Redistributable.
Happy tetrahedralizing...
UPDATE: The tetgen.zip has been updated with some fixes.
UPDATE2: This is now available on Food4Rhino: http://www.food4rhino.com/app/tetrino
…
Added by Tom Svilans at 1:27am on October 24, 2017
erona, nei giorni 01,02 e 03 dicembre 2016.
Il comfort visivo e la gestione dell’illuminazione naturale in relazione al risparmio energetico diventano sempre più rilevanti per una progettazione innovativa degli edifici. Ad esempio, il nuovo protocollo LEED 4 riconosce crediti per le simulazioni di daylighting e conferma l’importanza degli aspetti progettuali per “collegare gli occupanti con lo spazio esterno, rinforzare i ritmi circadiani, ridurre i consumi di energia elettrica per l’illuminazione artificiale con l’introduzione della luce naturale negli spazi”. Senza strumenti software per la simulazione della luce non è possibile ottenere risultati di qualità. Radiance è un software validato, utilizzato sia a livello di ricerca che dai progettisti ed è tra i più accurati per la simulazione professionale della luce naturale e artificiale. Non ha limiti di complessità geometrica ed è adatto a essere integrato in altri software di calcolo e interfacce grafiche. Queste ultime facilitano le procedure di programmazione. Le principali e più versatili saranno oggetto del corso (DIVA4Rhino e Ladybug+ Honeybee, plug-in per Grasshopper e Rhinoceros 3D).
Il corso è rivolto a progettisti e ricercatori che vogliano acquisire strumenti pratici per la simulazione con Radiance al fine di mettere a punto e verificare le soluzioni più adatte alle proprie esigenze. Sono previste lezioni di teoria e pratica con esempi ed esercitazioni volte a coprire in modo dimostrativo ed interattivo i concetti trattati.
Le domande di iscrizione devono essere presentate entro il 16 novembre 2016.
La brochure con i contenuti del corso e tutte le informazioni sono disponibili su questo link
Il corso è sponsorizzato da Glas Müller.…
BIM world.
I can well imagine that modeling your design would be a lot more cumbersome in GH. It does not lend itself to the kind of wall to wall 'algorithmic design' that GH is geared towards. I suspect the approach RhinoParametrics takes will yield comparably quick results. I think GH could equal this ease of use and eventually better the MCAD-style 'feature based' approach Inventor/RP uses.
The design has a lot of arbitrary setting out points, and parameters that are not amenable to an overarching mathematical formulation like 'replication'.
It also is more fragmented, where there is no obvious 'starting point' or 'root input' for the whole design. Not sure, but changing one 'roof assembly' look like it would need to propagate to the adjacent assemblies. This would be a problem for GH's DAG?
The arbitrary nature of the design components/setting out, would ideally be defined 'by hand' using traditional CAD event-driven techniques. I guess Inventor's 'features' are like mirco GH scripts that are placed and manipulated as part of its 'main loop', and provides the user all the feed back, alignment and snapping aids that have been accumulating over the years.
The snapping would also be 'persistent', and a geometric constraints solver built into its 'history tree'. Like most MCAD modelers, defining profiles with standard geometric/dimensional/algebraic constraints, using a 'sketcher' is pretty quick, and doesn't require any scripting. The 'declarative' way that the constraints are defined, is going to be far quicker than the 'imperative' / sequential way GH's relies on parametric math. I guess, GC will regain the upper hand when the design can't be described with constraints very well.
Constraints between 'parts' or groups of features would also be constraints-solved using a 3d constraints manager or kinematics solver. Needless to say, all the features are compiled, and tested/error-trapped against the comparatively restricted gamut of possibilities; i.e. other vendor provided features.
Inventor also has iLogic. Not sure if this was used. iLogic is interesting as it functions like an 'active spreadsheet' where the user can script 'rules, checks and reactions' that have full access to all of the parameters that drive the model's features. It uses VB, so I suppose you could get 'generative' with it via .NET. Probably not as comfortable as Catia's Knowledge Advisor workbench... still.
Would the best of both worlds be something like Inventor (for the mainstream stuff), but fully scriptable (for the esoteric stuff) in one app/thread? The user would weave between a DAG and MACD style history tree?
…
and...how to bake meaningful assembly/component type of structures for the rest of the tedious work required > you know what I mean > the ugly part of our business > documentation drawings, BOM, tech etc etc etc.
For instance, let's focus to the planar glazing support items: absolutely no need to make them it via any smart app since they are plenty of them around in the market (unless you are I.M.Pei and you do that exceptional Pyramid wonder thing).
But...the goal is...hmm...to create some kind of "smart" (kinda, he he) solution where components (the "baked" ones, so to speak) are structured in such a way that further work (via conventional CAD apps) is easily managed. To speak in Rhino dialect: nested Blocks and/or nested Refs. Like having components in GH that could manage nested Block/Ref stuff (but I guess that you can do it rather easily via VB).
Back to that ugly truss: It's obvious that this is a nested collection of "repetitions" (should I call them iterations?) : meaning that a void top node owns a module truss that owns 2 supportive sub-trusses that are made by some pipes that own connecting items that own the planar glazing items etc etc etc.
With regard the "own" thing: Imagine a CAD file that is simply a container/place holder of some individual entities (called Models). These Models can be "linked" to others (in a nested parent/child relation). Links can be external of internal. They can be either References or Cells or Shared Cells. This the way that Microstation classifies/handles "entities" (a bit primitive, mind, but nobody's perfect - for the real thing see CATIA/NX).
Back to that ugly truss: Obviously this structure (actually the assembly/component combo related with the given solution) has to be transfered into classic 2d extractions (say: plans, elevations, sections et all). This is done why a weird thing called Dynamic Views/live markers in Microstation (you define Clip planes in 3d space that manage 2d extraction content in something called Drawing Model that controls other weird things called Sheet Models, all these live linked etc etc).
To make things more spicy...these 2d extractions can been viewed as master detail directives: from where 1:1 classic details are made (that is: you apply more Dynamic Views and live markers and life goes on - red pepper extra strong Russian vodka is a must when you do that type of work).
This is where Rhino is out of his depth (but to be fair: it's not designed for this type of work) and also this is where Microstation has no competition at least for AEC purposes (but to be fair: it is designed for this type of work).
Of course Autodesk...well expect soon the Gen Comp equivalent for Revit...a fact that complicates things (for Bentley) a bit given the Revit mania in the AEC world.
Moral: intelligence is good but it's only the tip of the iceberg. …
e screenshot, there are only two ROT3D(rotation 3d) commands and SEC (Brep/Plane Section) are defined, it seems that the cylinders are generated at first, and the rotated planes are used to intersect the cylinders, in order to generate the curves.
[Figure 1]
The redrawing is based on the previous assumpation, and there are 21 pairs of cross-arc drawn[Figure 1]. Finally, the problem is focused on the last step how to intersect curves.
In CCX, there are only 21 run times, which means the curves intersection are looped one-by-one, and 21 curves are arranged to finished 21 intersection[Figure 2, plz zoom in]. That is the reason, why CCX is not able to get the cross points between the neighbour arc.
[Figure 2]
For the curve-to-curve intersection does not work, in order to get the intersection points, I try to enlarge the set of intersected component, using the plane or cylinder to intersect with curve. When the PCX (plane-curve-intersect) is tested, 21 curves are intersected with the previous 21 rotated planes, the loop runs 441 times, which shows that the curves are mananged to intersect with the neighbour plane, and the intersection points are found. Moreover, the SCX (surface-curve-intersect) is tested, and the 21 cylinders are successfully intersected with the 21 curves. And more important point is that the SCX makes the intection points exactly between the curves and the cylinders, while the redundant ones of the intersection of plane and curve, in some combination of the rotated angles and cylinder distances, are are avoided.
Besides, the Graft/Merge command is also tried, I hope to merge the curves list together, and to intersect them with each other, but it fails. It is supposed that the graft command may change the data structure. When a list of cylinders are grafted, the new data is no longer the cylinders, which fails to plot.
In conclusion, if the loops of geometry are in the same level, the command is run in correspondence; if the loop is between different types of geometry, the total trials of loop are run.
[Rhino Version 5.0; Grasshopper 0.9.0076]
BTW, the .gh file includes the initial base line, which could be run directly in Grasshopper. Please help me to check the model, thanks.…
have no mathematical falloff function, just an abrupt switch of field from zero to one in a way that somehow avoids nearly all bulging despite fields still at least arithmetically adding up where balls cluster....
I have newfound appreciation of David Stasiuk's Geometry Wrapper VB script. First of all, marching cubes actually gives a smoother result than tetrahedra, despite tetrahedra having a reputation of being "more uniform," in that tetrahedra can give aliasing that appears not as regular bulges but as sharp pyramids:
This can cause the smoothing step to end up with a somewhat directionally warped result.
But more so, Stasiuk's Geometry Wrapper, rather than bafflingly using a Grasshopper data tree as I thought and was disturbed by since scripting was my escape from those altogether, he is invoking a very fast special feature of Rhino via the Rhinocommon RTree feature that can search 3D space very efficiently, and thus his script is much faster than my Python version that is RTree ignorant. Here is his code:
Reference:
http://4.rhino3d.com/5/rhinocommon/html/M_Rhino_Geometry_RTree_Sear...
He also has a sophisticated way to define the bounding box at an angle that is often a lot more efficient than a dumb XYZ world coordinate box. Since Rhinocommon seems to lack a multi-object bounding box command except for points, it makes sense that he is populating curves with a few points to do it all via points. This makes it more complicated for me to adapt it directly to surfaces instead of pseudo-surfaces (via isocurve wireframe extraction) though, but I understand the script better now, so in time, perhaps.
For my application at least, I successfully made his script twice as fast by ridding it of a complex math function of the metaball radius in favor of just using the radius itself:
The script is also easier to understand now that I realize he early on assigns numbers to indicate object type, curve or point.
…
node geometry from line structure inputs.
In terms of trying to make all your panels regular hexagons... this topic comes up frequently on GH whether it be using only equilateral triangles, hexagons, pentagons etc;
http://www.grasshopper3d.com/forum/topics/folded-plane-subdivided-into-equilateral-triangles?id=2985220%3ATopic%3A1007963&page=2#comments
http://www.grasshopper3d.com/forum/topics/triangulation-using-only-equilateral-triangles
http://www.grasshopper3d.com/forum/topics/polygon-composition-with-hinges-1
In general, if you want a curved facade surface your hexagons cannot all be identical. There was a post on this forum about exactly this. I was convinced you could not have anything other than a flat surface with fixed, equalateral triangles but it turns out (and was shown by Daniel Piker and Kangaroo) that you can indeed have a non-planar surface panelled with equalateral triangles but it tends to be a kinked surface and it wasn't straightforward to control.
To try and reduce the variety of components in building structures like this, people have tried this sort of thing...
http://www.solidsmack.com/fabrication/you-can-now-build-your-own-geodesic-dome-at-home-in-under-an-hour-with-this-handy-kit/
...but notice the lack of panels!
Perhaps your best route is use something like what Bradley ended up with in the first link I posted then work on ID tagging each panel and node (and their orientations) so you have a construction procedure to follow.
One other thing to bear in mind... the simple construction above was really awkward to construct. On a larger scale it could be a nightmare! Once you have 2 nodes connected you can't fit the third without loosening the 2 that are already connected and shuffling them together bit by bit. Hard with 4 pieces, a disaster with many more so always think about how you intend to construct the pieces!…
ages do not distinguish between points and vectors, and sometimes not even between vectors and colours. GLSL shaders for example treat all coordinates, vectors and colours as 2d, 3d or 4d vectors.
However theoretically, and mathematically, they are very different entities and it is just easier to think with them if you keep them separate. As mentioned by Michael and Joseph already, points are locations in space specified using a set of coordinates, whereas vectors are directions+magnitudes in space, specified using a set of coordinate differences. Vectors are not geometry, and whenever we draw a vector in some specific place, we can only do so because we know, from the context, where that vector makes sense.
In physics and mathematics I'm given to understand that it often makes sense to denote points and vectors as either row-vectors or column-vectors respectively. I.e. either a matrix containing only a single row of numbers, or a matrix containing only a single column of numbers. In such an approach, points and vectors actually do behave very differently when used in equations and computations. But this is not something you typically have to worry about when dealing with 'simple' geometric stuff like CAD.
Conceptually, points and vectors are different things and as such they have different operations associated with them. Let's imagine we write points using round brackets (because points are dot-like nature) and vectors using angled brackets (because vectors are like arrows). Thus (x,y,z) would be a three dimensional point whereas ⟨a,b,c⟩ would represent a three-dimensional vector.
We can define a meaningful addition operation on two vectors by simply adding the respective magnitudes; ⟨a,b,c⟩+⟨i,j,k⟩=⟨a+i,b+j,c+k⟩. This operation takes in two vectors and outputs a vector. This turns out to be a useful operation because we end up needing it all over the place, for example when combining forces or motions.
We can also choose to define an addition operation on a point and a vector which looks (and is) entirely identical; (x,y,z)+⟨i,j,k⟩=(x+i,y+j,z+k). Note that this time the inputs of the addition are one point and a one vector, while the output is a point. This, too, is a useful operation because you can think of it as moving a point along a vector, which is something you need to do all the time. Are these two operations 'different'? Conceptually, yes. Computationally, no.
Would it make sense to define an addition operator which adds two points together? How about subtraction? How about multiplication? Well, sometimes it makes a lot of sense, sometimes it makes a little sense, sometimes it makes no sense. But by keeping points and vectors separate, I think there is less confusion, and I think it's easier to find mistakes. …
Added by David Rutten at 6:24am on October 21, 2017