hope you'd a Merry one,. 1) I used the Ln component to join vertices between each surface. As I was working with two surfaces I meshed each surface with an equal number of U/V divisions (Vertices) so was able to draw lines between each matching vertex.- ..by "meshed" i assume that meant converting Surfaces with MeshUV\DeMesh?, and from your screenshots thats a substantial number of vertices and therefore lines to draw, well worth it though from the results!, i agree with your answer to 3) that a more automatic solution is required,. 2) Equalizing is correct. When you mesh an object it will create vertices, and you can use these to re-create a mesh between each set of sub-surfaces. You don’t need to Sdivide after meshing. If you check the definition in my second post you should get the idea.- ..thats great news, equalizing vertex numbers is exactly what i need to do since my Blend surface "keyframes" by nature will likely have unequal point counts. However, a) ..when using default Rhino surf's your intruiging def. starting to work for me only after i replaced you "custom" Domain(VB\Python?,let me know) with Deconstruct Domain. then it connected each surf's vertices but did Not produce an intermediate surface or points. b) ..when using my IDENTICAL Blend surf's in your def. with Deconstruct Domain and Merge comp's it then produced intermediate vertices,.see def. screenshots or i can send def's i you like,.I'll also produce the 2nd, Non-identical Blend surf keyframe to test in your def.- 5) please show me which actual Domain etc. components or substitutes to use and how to use them to run your def. successfully? 3) This I am afraid I cannot provide concrete guidance on this. I am sure it is possible by drawing lines then matching vertices based on position relative to the ‘key lines’ however I don’t feel this would be a great solution. Better to create something that is more automatic.- .. agreed, 6) does or will your latest def. contain more automated, vertex correspondence, Ln creation? 4) Yes, you can use grasshopper Brep-join to join your sub-surfaces before you divide. See image below. Alternatively, if you are joining matching sets of sub-surfaces then you can morph each sub-surface with its corresponding sub-surface then join the whole object.- ..perhaps i missed something, but after using Brep > Join on my polysurface SDivide still saw it as subsurfaces instead of a single surface,. If you can upload an image of what you are trying to do I may be able to help more. My work evolved to some degree since I made these posts. I am now generating objects based on time stamped data from excel rather than objects in Rhino.- ..see screenshot "2-Def_shot.JPG" showing my two surf's beside Blended Rhino surfs which i need to do with mine,. How many sets of surfaces are you trying to merge through? It is also possible to morph from 1 to 2, 2 to 3, 3 to 4 …… x-1 to x by using a slider which calculates the range and picks the correct two surfaces to morph. If you need more info let me know and I will write something.- ..that sounds perfect, esp. since the sets of surfaces will be as nearly unlimited as the feature film they're modeled from. Yes, i'd love to learn more info\def's on this subject, thanks,.. I am planning to show some of my work and where my industry (civil engineering) is going with grasshopper based solutions. Will post a link shortly to some of my projects.- ..look forward to that as well, please keep me informed,..
I should be available most of today and days following so really look forward to heard back soon as you've free moments.
Thanks again for the great work as well,
big fan, Jeff…
ce attractors
3- Relation between mathematics and Form
4- Network surface and Paneling
5- Fabrication methods (slice3d, nesting, ...)
6- Structure and Architecture (Millipede)
7-Energy and form
8- Islamic patterns
9- Physics with kangaroo
…
ends to work well for Rhino+Grasshopper as well. There are a couple things to keep in mind though:
1) Rhino and Grasshopper are mostly single-threaded applications. It is true we are trying more and more to multi-thread certain operations, but the time when a high-core-count really makes a difference is a long way off. So, you should care more about the clock-speed of the individual cores in your machine than the sum total. I.e. 2 cores running at 2 GHz each are better than 4 cores running at 1.8GHz each, even though the former will often be marketed as a 4GHz machine and the latter as a 7.2GHz machine.
2) Rhino is an OpenGL application, so video cards that are awesome at DirectX but suck at OpenGL are a bad choice. There's a lot of information out there already about which cards are good and which are not.
3) Grasshopper uses GDI+ to draw its interface and GDI+ is rarely hardware accelerated. Basically, the faster your memory and the faster your individual CPU cores the faster Grasshopper will redraw.
4) Grasshopper should run on Rhino5 64-bit, so if you're getting a new machine make sure you have a fully 64-bit platform and a 64-bit Windows version to go with it. I'd also recommend at least 8GB of fast RAM.
5) If you can spare it, Solid State Hard-drives are faster than old fashioned spinning contraptions.
6) I also highly recommend getting a second screen, so make sure your vid-card is good enough to handle two displays.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 5:47pm on February 20, 2011
...doesn't apply here (in fact it doesn't apply in most AEC related cases) : we need a controlled loop thing (were the stupid part waits the smart part to choose things and/or reject others - that's the computer and you) in order to make a "stepped" evolving solution. This means Anemone/Hoopsnake components that could handle the whole process "interactively" based on gradually evolving/occurring criteria. I'm talking mostly about "Fork" situations that MAY occur - in plain English: columns that "share" the same base/top TS face. Of course N other situations (due to some engineering and/or aesthetics) may happen that prohibit the x "column" formation BUT only because some other columns are already in place. Maybe stuff for Galapagos?
3. This is evident even if this case could be used for non "strict" engineering purposes (like some academic form exploitation and other similar deep space stuff).
4. Αtractors are not available in the TS world (a rather easy/primitive way to influence a given column on a per column basis).
5. The whole process is exponentially heavy for your CPU since from column 1 the top+base+column thing is treated as a single TS.
6. Regardless ..before doing anything ... learn/master how Hoopsnake works and why (the fact that a Greek did that stuff is just collateral damage, he he). Galapagos is not a bad idea to fathom either.
BTW: most unexperienced AEC people believe that 21st century is about BIM (dead before birth). I say that all what should matter is evolving design/solution algorithms.
may the Force (and snakes)...blah blah
…
s to create an "inflated" structure (by balancing unary Z+ "forces" against Spring values and ...er ... properly selected Anchors). We must anchor some vertices on a per hole basis (or not: hole up in the sky). Ditto for the outer loop. If the Anchors are wrong (or "wrong") > Adios Amigos. If no Anchors: anti gravity is finally invented (I'm working on it, mind).
3. Since this type of stuff is the "same" (cost/engineering wise) no matter what Anchors we pick (provided that the max spans fall within reasonable limits) the only thing worth mentioning is the method for picking the Anchors.
4. One of the rare cases where aesthetics are clearly rated on top of the other design constrains (the other is tensile membranes). Do that in other type of Designs and ... become ... er ... hmm ... Zaha (avoid at any cost).
5. Code is required for doing this properly (AND managing design variations; in plain English: OTHER Anchor collections, that is). Code doesn't bite. GH is made with code, you know. Code IS my responsibility not yours : just press the red button and be a happy bunny.
6. So due to this (and that) finally we have the "inflated" thingy on hand. That's the peanuts part of the equation. Doing this in real-life ... that's the tears part (and THIS also requires code, lot's if real-life is real-life).
In order to clarify things I'll provide a series of "variations" (V1, V2 ... etc) on that matter. The first WITHOUT a pro policy for picking the Anchors: that way you'll understand (gradually) why the code is a must.
But ... maybe (just maybe) I'll do some entry-level freaky stuff with code for placing humans (or cats or dogs) in your terrain (as instance definitions).…
(Boundary Representation]. Thus a Brep is 2 things: the underlying "guide" surface and "regions" that do the massacre.
2. As delivered and if you chose the equivalent boolean some Delaunay faces are removed from the mesh IF their center (the projection in an automated made "min" plane) is contained (is inside) to a giiven hole. Now ... the anchors ARE not the white points ... they are their projections on the terrain (the red ones). Thus proper springs "pull" the white points towards the red ones.
3. Max span is a term used in that ugly part of life (the real-life) and indeed refers to some distance between mount points. For instance the Golden Gate has a max span of 1280 m. Span means money and big span ... er ... means lot's of money (even on trusses, considerably less so in tensile membranes).
5. Coding is like riding properly a proper Ducati (avoid the 999 at any cost): easy provided that you can ride it. Lethal in any other situation. But the good (or bad) news are that girls don't ride that type of bikes.
6. This makes me entirely off-topic > Oops > anything that I do/think points directly or indirectly (in most of the threads in this Forum) towards real-life AEC thingies. I never (ever) think within an Academic/Theoretical framework. BTW: Avoid social networks > or say hello to Skynet (or lobotomy).
7. You are very kind.…
oducts/207700-profile-connectors/25/1 ). Find one that can being fixed.
3. Design a custom aluminum beam (or contact Fipa) - BTW. Chinese do custom stuff for peanuts money.
4. Create the vault LBS first using the beams (the "skeleton").
5. Study Migua elastic inserts (critical) and Ceresit PE/S sealants. Get the gist of bridging gaps as a pro.
6. Use marine grade plywood only as a facet top cover (and some proper false ceiling). Plywood dimensions are usually 1.20 * 2.20 m. A 25 mm sheet could be OK for a small vault. DO NOT varnish the plywood. Epoxy glue linear aluminum L (10/10 mm) along the upper lips (in order to allow silicone to adhere properly (not shown in the image below) : failing to do that ... buy an umbrella).
7. Use trigonometry to calculate the variable beam placement per module.
Do this:
…
s the "Surface Populating" definition: I manage to populate my geometry over the surface, but after I bake it, I have to delete the boxes that define my components limits as well! Is there any way of populating and baking only the chosen component, without having to delete the boxes afterwards?
Secondly:
Basically: I am trying to cover a surface with two types of components [ an open one and a closed one] , which will be proliferated over my tubular surface according to the main sunlight direction.
1. I introduce the surface component.
2. I use "Divide Interval2" in order to have division into U and V.
3. i generate the target boxes [ "surfaceBox"] .
4. I use "Isotrim" ( same intervals) and "BRepArea" to find centroid of each area.
5. My "Curve" component introduces sun angle, with its "End Points".
6. I use "Vector 2Pt" to specify sun-light direction.
7. I want to measure the angle between sun-light and the surface normals, at the position of each component; after generating the centre points, I need the normals of each centre point to get the surface's points' UV, and "Evaluate" the srf at points.
8."Angle" and "Vector" components: I use them in order to evaluate the angle between the sun direction and the srf.
9. I convert this angle to degree by using a "Function" [ to see if the angle is bigger from the max.angle or not...]
10. Function "x,y" gives me boolean data.
11. Data become "Dispatch"ed...
12. Two "Morph" components , each one linked to one part of the "Dispatch" data, generate "closed" and "open" components over the srf.
The result should have been different types of components, based on the surface's curvature, diraction and sun-light direction...
I do not understand where the mistake is in this definition...
Thx in advance1
Spyros K.…
Component its manage a CSV like a Database, i found that the csv native Python module doesn't work in IronPython cuz its compiled in PythonC (or something like this), so i found a .Net module that can be imported to IronPython to work with CSV file
So Here a
Pseudo Code of my Toughs
1 - Import .net Module.
2 - Read Csv File. by a Path Assigned by interactive Imput.
3 - Identify the Header of The Csv File.
4 - Create a List of the Fields found in the Csv Header for Further (Sorting, Retrieve specific, create relations with others files by fields in commons, etc. etc. (whatever can imagine))
5 - Read the Data of the Csv File
6 - Out put the Attributes of the Header. (simple list of the fields to identify with what we deal for )
7 - Out Put a list of all the Attributes of the Header ( Complete List of the Fields by Rows Found in the Csv File.
8 - Out Put a list of all the Data inside the Csv File in relation with the Point 7.
over here's my thoughts Any Comment or Suggetions for the Component ?
i will be posting a Github for this, to all who want to collaborate with this.
i'm doing this cuz i'm dealing with a lot of amount of data in my Thesis Project, wich its focus on managing Shapes files, and Csv Files of Data that are not in the same dataset, so i need to relationate a lot of things just to develop my examinations techniques about the city.
…
ncluding an error) but the method did not lend itself to many similar shapes, especially those that are not surfaces of revolution.
Here is a technique using Anemone that finds a solution by climbing up a path determined by a teensy-weensy semi-cone. These are the steps:
1) Define a small semi-cone having the desired slope.(base radius/height) The smaller the better but it does begin eating up computing power.
2) Place the cone at the start point and find the intersection with the surface. Since the cone is small, the curve of intersection is almost linear and at nearly the same slope as the cone. Move the cone to the end of the intersection curve, reorient it based on the surface normal at that point, rinse and repeat.
3) Continue until the intersection event gives a null. The loop outputs the end points of each little intersection curve, so at the end, the list is flattened and they are interpolated into a spiral.
In the code I included a calculation for the percentage difference between the min and max slopes calculated, using a neat technique by David Rutten and the results go from a few hundredths of a percent for a pretty smooth surface to 4 to 6 percent for something more topographical. YMMV.
Assuming your machine is as slow as mine, it's cool to watch the path climb up and around the surface - if it's not, you don't know what you're missing! but to speed things up, check ''Output After Last' in the Anemone End Loop.
…