ay to make some real-life proper nodes for that kind of T truss (we use machined balls solely for MERO KK type of normal trusses).
3. I'll post here soon a modular demo system suitable for this case (real-life for AEC purposes - NOT for decorative/artistic stuff, I don't care about that since I'm an engineer). This would include a policy for the X struts that require a variable linkage (the X angle). and in the same time a multi cable tensioner "bracket".
4. "Basic" coding next week for T trusses ? Er ... well ... are you kidding me right? I mean that ... hmm ...
5. C# things (about 2+K) around me are classified into 2 "groups": things that are weapons in the right hands and others that serve as demos/start points for mostly abstract cases. The former are internal the latter for public use. I'll remove some sensitive lines from a T truss C# maker and I'll post it here as a "guideline" ... for ...hmm... 4.
All in all:
Provided that you have system(s) on hand (see 3) that work 100% OK in an ideal world you'll need:
A. Something that does the general topology AND (especially) clash detection. Maybe Kangaroo as well as a "first pass" with regard rigidity of the structure in case that you don't adopt a classic T "configuration" (there are many > Google tensegrity).
B. Connectivity trees that relate nodes/edges and maybe faces (say for roofing panels/curtain walls etc etc). Without them is impossible to assemble the T thingy.
C: Something that places real-life "parts" as instance definitions and/or (optional) a "tracking variants history" ability.
D. A bullet proof way to EXPORT things (on an assembly/component schema, say: STEP214 - see C) into a proper BIM app (the likes of AECOSim/Revit) and/or into a MCAD app (the likes of CATIA/NX).
E. FEA/FIM in order to validate the structural ability of the components and the T truss itself.
F. Roofing/cladding/envelope components.
G. "Interactive" cost estimation(s) - T trusses are hideously expensive at least versus "classic" trusses (exactly like a planar glazing system that retails 3++ times more than a humble semi-structural one)…
is the way the component was designed, but I love it and have used it multiple times.
You state:
Now for your position 3 the angle is either 0° or 180°. Since calculating the angle will always return both angle and reflex angle, you need to decide, which to use. AlignPlane uses minimal rotation. Hence your WorldXY will get no rotation at all for your position 3.
However... that's not actually true or what is happening. If you look closely at the image supplied in the original post you will see that the plane displayed at 180 is indeed rotated and the X vector is indeed pointing to -X. To double verify that I extracted the X vector from those planes and displayed them... clearly you can see in the image below that the AlignPlane component is rotating the plane at 180.
Now... to get back to the original issue. The problem I pointed out in my original post was not with the AlignPlane component, but rather with the OrientDirection component. It seems to me that component has an issue when fed a target direction of -X {-1;0;0} for a target vector.
To eliminate the confusion caused by the AlignPlane component I eliminated that component from the design and simply used rotated vectors as input to the target direction of OrientDirection. You will see that the results are the same... when given a target direction of {-1;0;0} the object is not rotated, while any other vector input does rotate the object.
I've attached the updated gh file demonstrating the issue using rotated vectors as the input for dB target direction of the OrientDirection component.…
ed rhino object with a uuid - as soon as i take it into a component the point comes out as a non referenced type and the associaiton, UUID, is broken to the original baked rhino object. This happened for a simple translation action using the move component - i specified a vector and moved all referenced points, output points were no longer reference types
For addition, if you use your idea of a uuid for a user string will it matter if you use addition as the two curves will have differnet uuids for the user string. The user could iterate through the user string collection on the created object to decide on which one to use. I guess the order of the user strings on the additive object is imprtant i.e. if A + B = C, then theorder of the user strings on C should be A, B
Some thoughts about how to maintian this.
1. If a grasshopper object is a reference type - the porperty IsReference can be used - then a new instance of a grasshoper object derived from any geometry that is a reference object has the option of copying that user string.
2. May be you can specify a global option as to whether to maintain inputted reference geometry user strings in components? May be a local option when right clickign on a components inputs where you can specify maintain input reference user strings
3. Restrict copying of reference user strings to certain componens where teh order and number of input parameetrs is unaltered when outputting - as you said, this should be the case for translation, scaling operations.
Not sure what the answer is, Im sure if you dont know the answer then nobody will know!!
Steve…
iew mode:
instead of the fabrication mode (individual Breps ready for 3d printing - minus "some" little details with regard their effortless connection > this is what V3 does):
2. GH does not (AFAIK) include the mesh.Offset capability (used a little C# for that).
3. I promise to translate the test C# used into native components ... if the result is what you are after (you never know, he he).
4. Rounding (fillet) the thickened panel lips (around the hole and with regard perimeter panels) is doable but only via code: AFAIK GH does not include the Surface.CreateRollingBallFillet method (something that does fillets, that is - forget it for the moment). In fact ... there's a complex way to do it without that method ... but is not for the moment (next week you'll be 100% more experienced, he he).…
ld be covered in concrete. I input the specs of the architectural fabric. E=.75 v=.3 p=610 and the thickness is .009. Whenever I run the study, and I've done so on several different meshes, it always produces several errant points. What do these points mean. Also when you divide 1 by the deflection does that convert the deflection to meters. I am also curious about the self weight input. Am I correct in assuming that a self weight of 1 applies 100% of all forces onto the model. I have been a big fan of your software and of your ideas and I still use topostruct since it's such a creative tool. I would like to learn more about doing studies in millipede but I need a little more info on what the various optimization setting should be and what tolerance values to apply. There are several inputs for these but I am unsure how to make adjustments. I have tried to follow your manual and demo files and they have been very helpful in getting me to this point but it seems there are some details I still don't get. If you can help explain or if you'd prefer I can provide you with the file to review. thanks …
s for the sunlight hours analysis.
I'm producing BRE Annual Probable Sunlight Hours calculations and so to match the BRE approach, I'm using 100 sun vectors, each representing 1% of probable sunlight hours. I could use the Sunpath and Analysis Period components to produce sun positions for the whole year, but this gives results that do not fully reflect the BRE methodology - which is important here. I'm detailing this just to clarify that this isn't a full annual calc of 8760 hours for 350 surfaces.
Anyway, when I run the calc, it takes about an hour to run, but the Sunlight Hours Component itself reports a calculation time of 3 seconds! Does this mean that the rest of the time is all about prepping the brep geometry? If so, is there a reason why this is much slower than when using a view of sky recipe and exporting to radiance. For the same project, I completed a view of sky calculations and based on the number of test points and -ad setting, this was completing about 5.25 billions rays so I understand why that took an hour.
Any thoughts as to why the sunlight hours calc seems to take so long?
thanks
Nick
…
omponent Srfgrid to work. I tried sorting the points and also tried all natural possibilities for the U-count from 0 up to 120.
The weirdest thing is that i can plug the same list of points into a Delauny Mesh and get the correct shell. However, when i bake this i get a Brep and not the solid i need for further research. Can anyone help me please? :)
…
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
ours looks like). Anyway, you'll probably want to start with a Fader 1-way. I set mine up to go from 0 to 300 over the course of 6 seconds. Then I just wrote a very quick C# component to check the output of the Fader component and whether it met one of three conditions. Here's the code (very simple). Note: you'll need to use the input manager to remove one of the Y input and the output manager to add 2 more outputs (B & C).
if (x <= 100) { A = true; B = false; C = false; } if (x > 100 && x <= 200) { A = false; B = true; C = false; } if (x > 200) { A = false; B = false; C = true; }
Now, we know if at any given Fader value if it's in the first phase, second phase, or third phase. I output a boolean value which can also be considered a 0 or 1 if converted to an integer. So, if I multiply those boolean values by 255, then the one that is true will be 255, and the others will always be 0. Now, you should have your color scheme which switches depending on what phase its in. Simply connect that to the Uno Write component (with the Firefly Firmata sketch loaded on your board) and send the color values to the board as PWM values.
Some things I should note... You probably notice the Fader component looks a little different (it's missing the start input and I'm using the GH_Timer). I've decided (for good reason) to abandon the Form Timer I was using in a lot of the Firefly components in favor of the newly re-written GH_Timer component. So, in order to get the Fader component to update in the next version, you have to connect a Timer and turn it on (not that much different). But, it's significantly faster. Part of the reason is that the form timer just wasn't fast enough to get really smooth results... Now, it's blazing fast. I've incorporated this Timer scheme in a lot of the Firefly components and the results are roughly 10x faster. Since, you're only switching values (and not trying to quickly modulate the PWM values) the current version of Firefly should be just fine (just use the Start input to start the Fader component). But, when we release the next version (hopefully very soon), this may change a bit. Anyway, I hope that clarifies it a bit. I've attached a screenshot below. I didn't include the file because I've got a newer version of Firefly that would just crash on you (or not open properly)... but hopefully you can get how to do it.
…
mething like an i7 with four cores would serve best. i am running 4x3.4 here. you should see 100% cpu utilization when solving.
2) model specifics: topology (= how many elements coming together in one joint), joint and support freedom, which both define the number of degrees of freedom of the model. the more DOF, the larger the stiffness-matrix to invert , the longer computation time. truss-bars are a LOT faster than beam elements.
3) loads and load cases: in general the more load cases, the longer the solving time. the more load vectors on single nodes (which it all comes down to), the longer too. but loads dont affect the computation time too much, especially since once the stiffness matrix has been inverted, most load cases can be applied to it i think.
eigenmodes take a LOT longer to compute than normal analysis, in certain karamba releases the automatic calculation of the first eigenmode (for debugging your geometry) was turned on inside the analysis module when something was wrong with the actual calculation to debug. this could turn out to be pretty annoying with big models so now it's turned off again.
with 'nonlinear', do you mean the large deformations iterative approximation component of karamba?
an average model with 10000 beams and three load cases takes ~400ms here, so take this times 20 for some non-linear iterations and you are there, roughly.
best
robert…