Vertices.Count * 3]; int[] facesizes = new int[m.Ngons.Count]; List<int> faces = new List<int>();
int j = 0; for (int i = 0; i < m.Vertices.Count; ++i) { verts[j] = m.Vertices[i].X; ++j; verts[j] = m.Vertices[i].Y; ++j; verts[j] = m.Vertices[i].Z; ++j; } for (int i = 0; i < m.Ngons.Count; ++i) { MeshNgon mngon = m.Ngons.GetNgon(i); facesizes[i] = mngon.BoundaryVertexCount; for (int j = 0; j < mngon.BoundaryVertexCount; ++j) { faces.Add(mngon[j]); } }
CarveSharp.CarveMesh cm = new CarveSharp.CarveMesh(); cm.Vertices = verts; cm.FaceIndices = faces.ToArray(); cm.FaceSizes = facesizes;
return cm; }
Going the other way should be similar, though I don't know if you need to define Mesh faces and then N-gons, or if you can just define N-gons right away and it'll take care of the Faces list for you... Haven't tried the Rhino 6 API... Not sure if you can just use the index operator on MeshNgon directly or you have to go mngon.Item[i] or whatever.
And then instead of
Rhino.Geometry.Mesh res = CarveRC.CarveOps.PerformCSG(...)
do
CarveSharp.CarveMesh res = CarveSharp.PerformCSG(CarveMeshA, CarveMeshB, CarveSharp.CSGOperations.Union);
Mesh m = res.ToRhinoMesh();
or your own CarveMesh-to-RhinoMesh function which preserves N-gons.
…
Added by Tom Svilans at 8:45am on September 25, 2017
nd added 'Path Mapper' and 'Flip' between 'Offset' and 'CCX'.
Then spent a lot of time trying to understand why it still didn't work...
Didn't like the 'Extend (Ext)' component here and thought it might be messing up the 't' values so used a different approach to creating the base line for each circle. I used 'Move' twice to copy the center of each circle in opposite directions, according to the 'VRot' vector, then created a line between them. It's more straightforward but didn't help...
Spent a lot more time(!) studying data trees - even used two copies of my 'vuTreeList' tool to isolate one circle and its lines (I left one copy in the file, disconnected). Finally managed the right combination of grafting the 'CCX B' and 'Shatter C' inputs and got the results we want - for half the circle.
Instead of making the same changes to the other half of the code/circle, I decided you probably want just one set of lines per circle, not two(?), so made some slight changes to the inputs for 'Series' that drives 'Offset'; I set the 'S' (Start) to negative 'Line Spacing' times 'Line Count' and set 'C' (Count) to "x*2". Then threw away the other half of the code!
…
inal surface will span over a rectangle with dimensions of 90m x 60m with many variations. Since I resized the surface it gets even worse. I cant get the edge lines connected to the edge curve. Might it be because of patched surface?
My idea is that I want to project voronoi on the surface and (maybe) trim it by edge curve. Everytime I try to creare voronoi it gets messed up already because at the edges it changes to these straight lines. Should I generate voronoi in the bigger rectangle below and project it afterwards?
Also it seems like afterwards in next step (projection) it cuts away these lines at the edge curve.
And the next steps are just missing the point afterwards, because the mesh is not connected.
My constraints are:
1) I need to maintain the length of the mesh elements after kangaroo optimization with length cca 3000 (it also affects the amount of voronoi points)
2) It has to maintain flexibility of the surface so it has to work whenever I change the shape of the surface.
…
ted a picture of in your post. The reason is that sound has larger wavelengths than light.
With a light rendering model, energy can be said to reflect specularly, relative to their geometry, because the wavelength of light is inifinitesimally small relative to any object you might have modelled. With sound, energy may travel and reflect diffusely, or move around objects, depending on the scale of those objects. Think of the fundamental equation of frequency to wavelength - speed of sound = frequency X wavelength. Using that, you can see that a wave in the 125 hz octave is about as tall as a human being (or maybe a little taller) and would easily move around your body, not being reflected at all. A wave in the 1000 Hz. octave band is as big as your forearm, and might reflect specularly from your torso. A wave in the 4000 hz. octave band is about as long as your index finger, and might reflect off of your torso, or even your head.
Similarly, if you were to model the seats explicitly, it might be relatively accurate at very high frequencies (say 4000 hz. and above) but that is a very small part of the answer. Consensus in the field is that the most accurate way to model the seats is with a flat plane, raised to about shoulder height, and then with scattering coefficients applied to represent the varying effects of geometry on sound. I tend to use low coefficents below 250 hz. (say around 30%) and high coefficents above 250 Hz.(90%).
Absorption depends on the seat which was chosen. This is often a good area to use for a model calibration based on measured reverberation time.
Arthur…
on the division points (see rhino screenshot below, left side is what I'm describing. there is also a note in the screenshot of the GH file)
Unfortunately it doesn't work for multiple cell inputs.
I've also tried flattening the points into one big list and re-creating the polylines with sublists but with no luck. The points are not ordered the way it would need to be to use sublists from domains created by 2 series of numbers. So this is problematic becuase each cell has a different number of vertices. That method would work if I can create unevenly spaced intervals that match the number of vertices on a given input, but I'm not sure how to do that.
Like would it be possible to create a series of numbers whos step size varies with each step? e.g. series that starts at 0, steps up in size 5, then 7, then 11, etc. ant there are x amount of values in the series?
Any ideas how to get this working? Either with this definition or a different method?
Thanks,
Brian…
Added by Brian Harms at 5:40pm on October 15, 2011
rganized around the courtyards.
Because the geometry it’s a bit complex I did not used the HB Masses to Zones component. I’ve also give the surfaces and massing a singular white opaque material as I only care for the window (glass material). I just want to calculate the DLA index on the surfaces of the library that it’s organized around the courtyards.
So I input the geometry in to GH run the analysis and somehow I don’t get any results. As if no light when through the windows surrounding the courtyard.
I’ve also did an image based simulation (illuminate type) in order to visualize the geometry as seen by radiance and it looks like the glazing is all black. I did verify the normal and they are all point outwards.
I was wondering also if LB re-color mesh component only work on flat lists. As the test surfaces are on a data tree structure and the component does not seams to read the same amount of meshes (message: length of the results [=X] is not equal to the number of mesh faces [=Y]). Even If I flatten the mesh list.
So any help would be much appreciate. We are at stage that we need to understand the daylight amount in the library as it’s a very important area of the project
Attached you’ll find the weather file, rhino and gh file
Thank you all in advance
…
e idea was to start with a basic Hex cells from lunchbox, make a curve from center, then make surfaces from those curves.
There are two obstacles for me as I see it:
1) i'm used to grabbing a normal from each cell, but cannot find out how to grab the local X value of each cell to create a vector, to create a line, to then make into a surfaces.
2) Once I have this centerline, how can I tell grasshopper which individual cell segments to make a surface out of?
That's the path I see to making the attached geometry anyways, maybe you all have a different suggestion for me to pursue?
A screengrab of my current definition is below as well.
I'm thankful for any advice you can offer on either or both of my challenges, or an alternative approach to replicate my Rhino Surface.
…
Added by Derek smith at 9:24am on December 28, 2015
rmation?" I know that this can already be accomplished using the brilliant Kangaroo plugin, but I wanted a simpler and faster (yet still accurate) single component that could replicate this unique curve using a variety of inputs: the length of the rod/wire, the width/distance between the endpoints, the height of the bend, and the tangent angle at the start. I also wanted make the unknowns (such as height if only length and width are known) easily accessible for plugging into additional components.
The resulting script, being an all-in-one solution, is somewhat unwieldy, but it could easily be broken down into smaller components (custom .gha's which I don't have the ability to code). If someone wants to tackle this, please do! I'm not an expert coder by any means, and as this was only my second time diving into Grasshopper scripting, if the script seems somewhat strange, that's probably why. I did try to comment the code pretty well though. Here's the full description:
--------------------------------------------------
DESCRIPTION: This beast creates the so-called 'elastica curve', the shape a long, thin rod or wire makes when it is bent elastically (i.e. not permanently). In this case, force is assumed to only be applied horizontally (which would be in line with the rod at rest) and both ends are assumed to be pinned or hinged meaning they are free to rotate (as opposed to clamped, when the end tangent angle is fixed, usually horizontally). An interesting finding is that it doesn't matter what the material or cross-sectional area is, as long as they're uniform along the entire length. Everything makes the same shape when bent as long as it doesn't cross the threshold from elastic to plastic (permanent) deformation (I don't bother to find that limit here, but can be found if the yield stress for a material is known).
Key to the formulas used in this script are elliptic integrals, specifically K(m), the complete elliptic integral of the first kind, and E(m), the complete elliptic integral of the second kind. There was a lot of confusion over the 'm' and 'k' parameters for these functions, as some people use them interchangeably, but they are not the same. m = k^2 (thus k = Sqrt(m)). I try to use the 'm' parameter exclusively to avoid this confusion. Note that there is a unique 'm' parameter for every configuration/shape of the elastica curve.
This script tries to find that unique 'm' parameter based on the inputs. The algorithm starts with a test version of m, evaluates an expression, say 2*E(m)/K(m)-1, then compares the result to what it should be (in this case, a known width/length ratio). Iterate until the correct m is found. Once we have m, we can then calculate all of the other unknowns, then find points that lie on that curve, then interpolate those points for the actual curve. You can also use Wolfram|Alpha as I did to find the m parameter based on the equations in this script (example here: http://tiny.cc/t4tpbx for when say width=45.2 and length=67.1).
Other notes:
* This script works with negative values for width, which will creat a self-intersecting curve (as it should). The curvature of the elastica starts to break down around m=0.95 (~154°), but this script will continue to work until M_MAX, m=0.993 (~169°). If you wish to ignore self-intersecting curves, set ignoreSelfIntersecting to True
* When the only known values are length and height, it is actually possible for certain ratios of height to length to have two valid m values (thus 2 possible widths and angles). This script will return them both.
* Only the first two valid parameters (of the required ones) will be used, meaning if all four are connected (length, width or a PtB, height, and angle), this script will only use length and width (or a PtB).
* Depending on the magnitude of your inputs (say if they're really small, like if length < 10), you might have to increase the constant ROUNDTO at the bottom
REFERENCES: {1} "The elastic rod" by M.E. Pacheco Q. & E. Pina, http://www.scielo.org.mx/pdf/rmfe/v53n2/v53n2a8.pdf {2} "An experiment in nonlinear beam theory" by A. Valiente, http://www.deepdyve.com/lp/doc/I3lwnxdfGz {3} "Snap buckling, writhing and Loop formation In twisted rods" by V.G.A. GOSS, http://myweb.lsbu.ac.uk/~gossga/thesisFinal.pdf {4} "Theory of Elastic Stability" by Stephen Timoshenko, http://www.scribd.com/doc/50402462/Timoshenko-Theory-of-Elastic-Stability (start on p. 76)
INPUT: PtA - First anchor point (required) PtB - Second anchor point (optional, though 2 out of the 4--length, width, height, angle--need to be specified) [note that PtB can be the same as PtA (meaning width would be zero)] [also note that if a different width is additionally specified that's not equal to the distance between PtA and PtB, then the end point will not equal PtB anymore] Pln - Plane of the bent rod/wire, which bends up in the +y direction. The line between PtA and PtB (if specified) must be parallel to the x-axis of this plane
** 2 of the following 4 need to be specified ** Len - Length of the rod/wire, which needs to be > 0 Wid - Width between the endpoints of the curve [note: if PtB is specified in addition, and distance between PtA and PtB <> width, the end point will be relocated Ht - Height of the bent rod/wire (when negative, curve will bend downward, relative to the input plane, instead) Ang - Inner departure angle or tangent angle (in radians) at the ends of the bent rod/wire. Set up so as width approaches length (thus height approaches zero), angle approaches zero
* Following variables only needed for optional calculating of bending force, not for shape of curve. E - Young's modulus (modulus of elasticity) in GPa (=N/m^2) (material-specific. for example, 7075 aluminum is roughly 71.7 GPa) I - Second moment of area (or area moment of inertia) in m^4 (cross-section-specific. for example, a hollow rod would have I = pi * (outer_diameter^4 - inner_diameter^4) / 32 Note: E*I is also known as flexural rigidity or bending stiffness
OUTPUT: out - only for debugging messages Pts - the list of points that approximate the shape of the elastica Crv - the 3rd-degree curve interpolated from those points (with accurate start & end tangents) L - the length of the rod/wire W - the distance (width) between the endpoints of the rod/wire H - the height of the bent rod/wire A - the tangent angle at the (start) end of the rod/wire F - the force needed to hold the rod/wire in a specific shape (based on the material properties & cross-section) **be sure your units for 'I' match your units for the rest of your inputs (length, width, etc.). Also note that the critical buckling load (force) that makes the rod/wire start to bend can be found at height=0
THANKS TO: Mårten Nettelbladt (thegeometryofbending.blogspot.com) Daniel Piker (Kangaroo plugin) David Rutten (Grasshopper guru) Euler & Bernoulli (the O.G.'s)
--------------------------------------------------
Edit: More on the math behind this here.
Cheers,
Will
…
Added by Will McElwain at 4:08pm on February 26, 2014
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
…
stributes structural supports for a uniformly loaded domain using e.g. the internal energy of the loaded domain as fitness. Here the uniformly loaded domain is represented by the trimmed surface. My genomes are the support positions (green crosses), which are restricted to a set of predefined grid points. I’m currently using an (i,j)-coordinate indexing for these grid points (illustrated in the viewport just below) as opposed to a sequential , “one-dimensional” numbering (illustrated in the viewport further down).
(i,j)-indexing systemAltenative, sequential indexing system
The support positions are computed by two gene pools; one governing the i-index, Gene List {i}, and one governing the j-index, Gene List {j}, of each support. The value of slider 0 in Gene List {i} is paired with the value of slider 0 in Gene List {j} etc. and the amount of sliders corresponds to the amount of supports. The screen shot below depicts the slider constellation corresponding to the support distribution depicted above. Unfortunately the j-index represented in the sliders needs remapping as the number of j-indices vary for each i-index (horizontal row of grid points). With the current setup I have 12^6 x 9^6 = 1,6 x 10^12 different genomes. If I were to use the sequential, “one-dimensional” numbering, I would only use one gene pool with sliders ranging from 0 to 76 meaning that remapping could be avoided and thereby having only 76^6 = 1,9 x 10^11 different genomes.
So, my current genome setup causes a bunch of issues related to the Evolutionary Solver: Remapping Changing one of the j-index sliders, will not necessarily change the related support position but it will still facilitate another genome to be calculated by the solver. (This problem could be eliminated by using the sequential, “one-dimensional” numbering)
Switching slider values around If the values of e.g. slider 0 were to be switched around with the values of slider 5, this again would yield a new genome but an identical solution. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
Coincident support positions Two or more supports may be located in the same position. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
I find it impossible to imagine the fictive “fitness landscape” of this problem and not only because of the multidimensional genome characteristic but just as much because of these listed, intertwined peculiarities. I’ve tried running the Simulated Annealing Solver as well, but my experience is that the Evolutionary Solver yields better results. To my awareness, the solver uses some kind of topographical proximity searcher. This is why, I think that the solving process itself benefits more from analysing the (i,j)-index system, in which neighbouring grid points hold more uniform topographical information than the sequential, “one-dimensional” numbering, which might have big ID-numbering gaps between neighbours. Have I understood this correctly?
Cheers…