ts (NOT meshes) using my (still WIP) BallPivot thingy (still highly temperamental despite wast quantities of Vodka consumed - in the Name Of Science, what else?):
Watch this Forum for the forthcoming mother of all threads : Get Points > Do Something.
On the other hand (real-life):
1. A truss without connectivity is nothing.
2. A truss without clash defection is nothing.
3. A truss without instance definition(s) is more than nothing.
4. A truss without (rather very complex that one, mind) roof/envelope stuff is nothing + pointless.
5. Mesh from points without a 1000% working ball pivot thingy is like 3rd marriage.
And as you'll discover this Monday ... well ... "some" things would be MIA from the definition.
Other than that:
For Chap, David, Angel and anyone else interested on these freaky things (get points do something, that is).
Do you people think that this (mode: dense [yellow stuff] ) has any meaning?
VS that (mode: hex):
I mean for the truss itself not the roofing paraphernalia. Notice that in this handsome hex mode we've already achieved max rigidity since we deal with tetrahedral stuff.
PS: My aunt Drusilla finds the dense mode ... utterly pointless (and a bit disgusting).
That's friends is the 1M question.
…
ly the operative temperature, to, as an input) you can consider ta, tmr and the air velocity (v).
If there are all the data (ta, tmr and v) you can consider this equation.
If there are not the v values you can approximate to with this equation.
In the psychrometric chart component you can modify the “mollierHX” input and transform it from a Boolean input value to a numerical input and name it, for example, “chart type”: you can set 0 for the classic chart, 1 for the mollier HX plot, 2 for a (to,x) chart and 3 for a (t, RH) plot.
In a (to,x) chart, if the ta or the tmr increases (or both), the to moves to right, so if there is a RH of 100% the red point moves as for the case 1. If ta or tmr (or both) decreases the red point moves to the left (case 2).
…
sion app (Modo, Z Brush etc) in order to get "as equal" as possible mesh faces.
For instance ... see a W depth truss (tri mesh > meaning that the "out" grid is hexagons) out from a Kangaroo "inflated" mesh:
2. A space frame is NOT a collection of abstract lines ... meaning that clash members detection (via trigonometry and NOT by checking boolean intersections) is far more important than the "concept" it self. If "live" alterations are required for addressing local clash issues ... well ... that's 100% impossible with native components.
See a typical clash detection capability:
3. A truss without proper connectivity Data Trees means nothing in real-life (vertices to edges, vertex to vertex, edges to vertices).
4. Each "standard" truss member (say: sleeves, cones and the likes) should be an instance definition placed in space according appropriate orienting planes. That way you may be able to handle thousands of components that in real-life participate in any truss of a certain size.
All the above are far easier to do with code (V4 is impossible with components).…
w how. Thanks for that. Now I do have some questions.
1. I am using the area weight tool. I am first calculating the volume of the form. I then multiply that value by it's density. So for concrete I am using 2400 kg/m^3 x volume. I then divided that number by the area of the membrane that is supporting the mass. This gives me my area weight. It seems to be working well but I want to verify that this is the correct workflow. I also want to verify that gravity would be turned off since I am thinking it is already calculated within the weight component.
2. I am finding that the new triangular element tool works much better than trying to use EA/L as input for the springs from mesh. Even when I set the timestep, subiteration, and drag I still have issues with getting very stiff materials to work. On the new finite elements tool I wanted to verify that E was in pascals. I also wanted to ask if I use imperial units can psi be entered. Now from what I am seeing the materials are deforming more than expected and to get less deformation and stretch in the mesh area I am finding the E value needs to be increased more than the true material values. Often I am raising E by a multiple of 10 or 100.
I am going to describe my problem and I will gladly share the definition if you'd prefer looking it over but basically I have an inflated membrane at a certain pressure made of a particular material. I then have a certain volume of concrete on top of the inflated membrane. My goal is to review the displacements as the concrete is applied over the membrane and find the proper pressures to apply to keep it free from deformation. I am including a picture from a project that we used kangaroo on and attempted to deal with such issues. It was a class sponsored by Cloud9 architecture held at Art Center College of Design where I was one of the instructors. Hopefully this illustrates the problem. To summarize any example file that shows the best way to implement real material properties and unit based forces would be a helpful reference and would be greatly appreciated.
…
ly this is a Rhino.Python problem and not a Grasshopper issue, but it could apply to both!
I was trying to take a simple example of moving a ball around and see how it could be animated through Rhino.Python. The code works great in wire frame with now memory issues at all. However, when I switch the view to Shaded or Rendered, things go south pretty quickly. The RAM usage of Rhino which was steady around 350mb (ish) now grows every frame after a minute or so, it is in the GB's and never drops even after the script has stopped.What gives? Clearly this must be possible because Bongo does something similar when it does animations. Check out my code below and I would love to hear your thoughts.
import time
import rhinoscriptsyntax as rs
import Rhino
height = 100
width = 100
x = 0
y = 0
xspeed = .1
yspeed = .3
start_time = time.time()
end_time = 60
run_time = 0
sphere = rs.AddSphere((x,y,0), 5)
while run_time < end_time:
x = x + xspeed
y = y + yspeed
if x > width/2 or x < -width/2:
xspeed = xspeed * -1
if y > height/2 or y < -height/2:
yspeed = yspeed * -1
rs.MoveObject(sphere, (xspeed, yspeed, 0))
Rhino.RhinoApp.Wait()
run_time = time.time() - start_time…
uts an instance of a class type, which I refer to as Class Instance A for this discussion post.
Component B, has a for-loop, through which it does a few things, and makes "n" number of variations (in this case, just 3) of Class Instance A. Simplified/generalized structure of Component B is as follows:
a=[]
for i in range (n):
.....variation = DoSomething (StartShape)
.....a.append(variation)
.....for obj in ghenv.Component.OnPingDocument().Objects:
..........if obj.Name == "MakeAssembly": ...............obj.ExpireSolution(False)
I am not sure if I am using the ExpireSolution method correctly here. I also have found this (Grasshopper.Instances.ActiveCanvas.Document.NewSolution(False)) from some other discussions, but it doesn't seem to solve this problem. Or maybe I have the placement of ExpireSolution or NewSolution wrong. Upon pressing F6 then F5, Component B keeps updating Class Instance A, instead of "resetting" it to its original condition. For-loop in Component B must have the original Class Instance A every time, in order for it to spit out variations. I need to find a way to expire the solution for Component A only, at the end of each For-loop. Eventually, I need it to loop 100+ times, so manually pressing F5 is not really an option... Below is an image of what should happen:
What is the best way to tackle this problem (in either Grasshopper-Python or IronPython), so that the same original Class Instance A is fed in every time the loop is run in Component B?
Thank you! …
aching my skill set here, but bare with me.
I want to create an animated facade of squares which rotate depending on a sequence of grey-scale images. I've got pretty far thanks to many discussions here, but have hit a blank with exporting my animated model to 3ds max.
Here's my GH script - it's a botch of 3 or 4 various things incorporating centipede at the start and end to get the animation.
All good and it works! It produces animations which I can sequence for presentations too thanks to it's bmp export, which is sort of a side-product.
What I have a problem is that the OBJs it produces error wildly when imported to max. eg in rhino it looks like
But when I've imported them to max it looks like
and as it animates it just gets longer and smaller.
NOW I reckon it might be because my model in grasshopper is 100 separate geometries and it'd like it to be a single one - but I've not achieved that.
Does anyone have any ideas how to solve this? My end result I would like to look like this rendered still from max, but animated.
Thankyou all! This also uses Firefly, so you might need that installed to see how my file works.
…
Added by chris parrott at 10:34am on September 11, 2015
reaky thing consisting from triangulated "modules" (i.e an assembly out of this, this and that) where the exterior edges ARE always under tension (= SS 304/316 cables OR nylon) and the interior ones MAY be under compression ( = steel, aluminum, wood, carbon) OR ... some of them ...may be under tension. Bastardized T trusses deviate a bit from theory ... but who cares? (not me anyway). T trusses have many variants (but as the greatest ever said: Less is More).
2. Large scale T for AEC is the art of pointless since it costs around the GNP of Nigeria. Here's some indicative components from a module of a multi adjustable TX system costing (the module) ~ the price of my Panigale (Google that):
The above is mailed to a friend who has MIT (yes, that MIT: the top dog) on sight ... therefor he needs some appropriate "credentials", he he.
3. The distance that separates the above with the demo TDT node provided is around 666.666 miles - but we don't care: we are after Art not some testimony to vanity.
4. On purpose I've used a smallish ring to give you a clear indication upon the constrain numero uno in truss design: CLASH matters.
5. You'll need:
(a) A decision related with the tensioners (classic Norseman + SS cables or nylon machined thingies?).
(b) A machinist who can do elementary stuff (like the adapters) and can weld this to that (the "ring" for instance). His abilities must be 1 in a scale of 100. If the fella has a computer (not a CRAY) and he knows what 3dPDF is (hmm) ... well ... use that way to communicate with him PRIOR designing anything: He must agree on the parts BEFORE the whole is attempted (as a design in GH or in some other app).
(c) A carpenter with a wood lathe for the obvious. BTW: BEFORE doing any TDT attempt > ask the carpenter about the available wood strut sizes. Against popular belief DO NOT varnish the wood (use exterior alkyd/oil stains from some top maker like the notorious US company PPG).
http://www.ppgpaints.com/products/paints-stains-data-sheets
(d) Good quality cigars (and espresso) plus some classic music (ZZTop, PFloyd, Cure, Stones, U2 etc etc) during the assembly.
(e) Faith to the Dark Side (see my avatar).
May the Force (the dark option) be with you.…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
Context sensitivity."There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
Components."Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…
ntrol points in Rhino.
Also, I forgot to mention in part 1 that when doing the directional subdivision, depending on how you drew your input mesh, there is a chance that it gets divided in the wrong direction, and you end up with something like this:
Which is not what we want.
The simple way to fix this is with the MeshTurn component, which rotates the direction of each face by one side:
Now we can use physical relaxation to smooth our mesh. In this example I show a simple tensile relaxation, so it will be negatively curved, but the same principles can be applied to all sorts of surfaces by using different combinations of forces.
The definition for the relaxation is attached below.
There are 3 main groups of forces used:
Planarization
For the mesh to be able to unroll properly into flat strips, we want each of the thin rectangles to be flat.
Springs
I already showed how the WarpWeft splitting can be used to assign different strengths to control the shape of a mesh here. Now because of the uneven subdivision we have very different numbers of edges in each direction, so the strengths have to account for this. Depending on the level of subdivision used and the shape you want to achieve, you may need to set the Weft stiffness to be 10 to 100 times that of the Warp.
Edge Smoothing
Because our subdivided mesh has square ends, we might not want to simply anchor the boundary, so I've shown how we can force them to become more circular, while still staying in place. Each boundary curve gets pulled onto its best fit plane, while also applying bending to round it out, and springs to keep it from shrinking.
(This part could also be achieved in other ways, such as pulling the boundary vertices to a curve)
When we run this relaxation, the shape should smooth out to something like this:
Play with the tensions and boundaries until you are happy with the result, wait for it to stop moving, then stop the timer. (Remember it is very important to always stop the timer once the relaxation has finished, before continuing working with the output, as otherwise Grasshopper becomes very slow, because Kangaroo is constantly resolving, even if no movement is visible).
If you want to try other shapes than tensile surfaces, you could also use forces such as bending, laplacian smoothing, or pulling to some target surface to control the form.
Next - Part 3 splitting and unrolling
…