Hi Peter, thanks for your contributions and experiences shared.
Sorry, but my project is research related, fortunately I have no clients nor advisors telling me what are they going to pay for and what they aren’t
I just want to compare several tower-like alternatives for some research project. In tall buildings and tall towers (e.g. for wind power generation) weight efficiency is an issue. This is the reason of my obsesion for equal angles and geodesic stuff.
I already have some UV meshing based designs, but now only the “equal angles” design is left. I’m having some success in the iterative approach (based on Anemone), but I’m having some problems by nesting two “for” loops. If I don’t succeed today I would open a new thread about it. I hope not need to bother you with this looping issue
Hmm … see the sketch above and imagine doing the dots with index 1 for even branches and 0 for odd. Kind of zig-zag “near” the IsoCurve that suits you best. Then you combine each dot with the previous and the next and you get the 2 related short paths (per, say, even branches). Then you extend them and you get your geo chaos. Then is a classic Curve/Curve ccx task.
Hi Peter, your script and C# code look very nice and it is very fast too! Thank you very much, I will try what you say with the extend option once I debug my buggy-looping approach. I think I will start a new thread soon before turning crazy , stay tuned…
By the way, this is one of the non-loop design options I´ve found so far (Mesh-UV based). As you can see angles at top are very different from the ones at the base.
Hi and thanks again, I think I can´t do what I want using your script and the “shortpath and extend approach”. When I try to extend from uv point 1 (0,0) to some other uv point 2 the curve usually bounces back instead of keep going up until it reaches the cylinder top. Check this example:
… and indeed the ExtendOnSurface Method yields this bounce back result: one should expect the opposite mind … meaning that this idea is just another stupid thingy.
BTW: I fully understand your quest for non truss based LBS solutions … but nothing beats a good old W truss (most notably these days where carbon fibre is available to the masses meaning ultra light CF tubes etc etc ). The old thing again: the more things change the more stay the same.
On the other hand … since you can have a ShortPath on a cone/tube (“top to bottom”) … is your issue just about how to have a “grid” of these (i.e. what u1/v1 - u2/v2 values to use) ? If so time for V1B
Not sure if this is relevant, but I played around a bit with a Kangaroo method that might be of use.
I haven’t tested whether the strips here are of a constant width, but their edge curves should be geodesic to the cone?
I´m sorry, but my issue requires that the helical (or diagonal) beams be able to turn around the conical structure (even several times). It seems that your “top to bottom” approach uses the geodesic (shortest) path, and so, it cannot turn many times.
I´m close to finish my loop-based solution. It iteratively computes first the intersection curve between two cones and then the intersection of the later with the surface to determine the next level points. As you can see, it is able to turn whatever the required times around the cone and, at the same time, maintain a constant angle of the helical beams with the vertical axis. Here is my first animation in GH, sorry for the bad quality!
Hi Nick, thanks for your kind contribution! It looks very interesting. I´ve tried to take a quick look, but I have a couple of plugins missing. I will look for and install them later, and will let you know if it works. Thanks again!
Apologies. Here is a quick edit that wraps a single strip but only uses native GH/R6 components. I can help update it for multiple strips a bit later, but this will at least introduce the idea to see if it’s of use to you.
Hi Nick, I installed MeshEdit2000, and played a bit with your solution. Unfortunately, I was not able to obtain geodesics that turn around the cone more than 180 degrees, i.e. like the thin black lines in the cylinder from post number 3. Is this possible with your solution? Thanks!!
If you are solely after cones … this is solvable in real-time (say 5 milliseconds for 1+K points) via classic trigonometry and some recursion. Notify if you want a C# that cuts the mustard on that matter. But the gains in dollars for such a LBS would be rather academic. Would be faaaaaaaaaaar more challenging and meaningful to design (not with Rhino) a proper “modular” node for your HPE/HEB/HEA/IPN/etc members.
Other than that here’s what are you after:
Starting from R0 and given a step d and pts according some division value … you can get easily R1 and the bottom most white and red pair. So … you are after X that yields the upper (i.e. next) white/red pair where their angle is the same with the bottom pair. And so on … until you reach some max H (that is the sum of all solved d’s). You can solve this via trigo or classic Plane/Plane ccx stuff.
… and is rather the fastest way to deal with a similar issue. Truth is that nobody would be after a zillion nodes for some sort of AEC tower… but if this is only the prelude (towards a real-life LBS system that includes FEA and many other things) … well … every millisecond counts.
On the other hand: assume that the one way of the other we get a LBS with “steady” angles (within a given atol obviously: atol = RhinoDoc.ActiveDoc.ModelAngleToleranceRadians) and then we proceed further on. But wait … what means in real life such an angle? Is it some abstract value that if achieved everything is OK? Far from that: you should outline/design a realistic node as well (in most of cases with big members involved). So … the smaller the angle the more arbitary checks are required. Count the fireproofing layer as well that in several real-life cases is “bigger” than the protected member. Etc etc.
The WIP thing goes well (1K nodes solved - on average - in 1-2 milliseconds). LBS angle reported is the half angle (I like confusion).
Must cut that time by a factor of 5 (case: tower with 5667777766789999 nodes). Must control the angle accuracy with some better way (for those working at NASA, that is). See the 68.7 angle that has …er … a big difference VS the 68.8 angle (this may result a million dollars gain or even a billion or a zillion (LOL)).
Question is: what kind of modes (i.e lbs axis member combos) are required? Like the one shown? Maybe some other(s)? What other(s)? (sketch required).
Good point, and I should be more clear for the sake of the thread.
By “sufficient” I meant whether @Vigardo needs to be able to set a variety of initial wrap angles, or just use the angle set by the diagonal of the mesh faces. In the latter, they are limited to a solution space that is much less nuanced and depends on the mesh subdivision, but I suppose if the structure is set, this may be simple enough. Not at all implying your solution was overly complicated. Looking forward to tinkering with your work above - super nice!
However, I just need to set an initial constant angle that must be maintained at all heights. And it must work with “any” surface of revolution. (I say “any” because the chosen angle imposes some restrictions to the curvature of the selected surface).
Nick, your mesh approach is interesting but not valid for my project. It would lead to issues to define the mesh size (variable to maintain the same angle). Tanks!
Peter, I´m not solely interested in cones. Cones would suffice but only as last resource. Ideally, I wanted it to work with “any” surface of revolution. Btw, great illustrative sketches!
Thanks for your efforts, but my loop-based solution (see post 13) already works. It is slow but I think it is because of the Anemone loops. I´m working on it (sorry if it takes me some time to answer you properly).
Hi all, sorry for the delay. This the minimal working example of my “constant angle” approach: TowerNurbConstantAngle.gh (66.0 KB)
Despite it works with cylinders, cones, and nurbs revolution surfaces, it is very slow. To address this issue, I´ve tried two different looping plugins. Fast Anemone takes 260 ms to build a 11 floors (i.e. iterations) tower, and Octopus-Loop over 600 ms. I was not able to use HoopSnake here, it seems that it is not as “flexible” as the other looping tools. The things go much worse, i.e. over several seconds, for higher tower heights and angles… Would you help me to speed this up?
In this small example, the GH profiler indicates that the bottleneck is the computation of the intersection curve between each pair of cones, i.e. the BBX (6 ms) component. Perhaps @PeterFotiadis has some ultra-fast solution for this
Figure: This is the main loop. You can switch between Anemone Fast, Anemone Classic, and Octopus looping approaches by Disabling the corresponding components. All were already wired to work. Perhaps you need to double click on the loop component to reset.
PS: The exact angle and the number of floors required to match the given height slider is WIP (I know how to do it, but it is not fully ok yet).
Other than that my conical C# explained above could been easily modified for accepting any revolved Surface … but that would require ccx events (Plane/Profile curve) and tangent calculations instead of trigonometry and may require 5+ times more time: from 2 milliseconds (A crap slow i5 used for the tests, in an i9 or Ryzen expect ~1 ms) up to 10 or even more.
PS: Did some minor changes here and there: for 40 “layers” and 4.6K truss axis (Lines) this is the average time (i5):
I´m not after any tower in particular, it is just a general tower-like structures for some master degree project. But windmills would be a good example application.
I did a simple profiling test (compute the intersection curve between two cones) and it evidenced that it takes similar times outside and inside the loop… so it is just a matter of GH speed. I´ve haven´t ever figured out that GH with a modern i7 (4.0 GHz) computer would run that slow…
If something is slow in 99.999% cases is your fault in the sense that you are (quite possibly) using some very expensive (time wise) Method to do that something.
That said this is easy to claim if you can write code (in order to by-pass some slow add-on) but not so easy if you can’t.
That said David R (the GH man) did a rather mighty work in the native GH components: they perform more or less quite fast (or very fast). First class work, that is.
But … whatever David does … there’s absolutely no reason to do Cone/Cone ccx in order to find your next points for revolved Surfaces. I mean … you can obviously do it but expect to pay the price. Is kinda trying to go fast with the 1st gear in your gearbox.
I’ll give you a small example: Assume that you have to divide a Curve by count. If you use the Curve.DivideByCount … R Method this takes X milliseconds. If that Curve happens to be a Circle and you use classic trigonometry this takes Y milliseconds. Now in order to spot the difference … just … do the above in parallel using 1000 Circles.
So always blame you if you missed another way to cut the mustard (provited obviously that such a way exists).
I´m using the standard BBX component to obtain the intersection curve between two surfaces. There it seems that there exists some Rhino method (named Surface Surface) that would be faster, put I don´t know how to call it from GH.
You say that “there’s absolutely no reason to do Cone/Cone ccx in order to find your next points for revolved Surfaces”, then how would I obtain the next points in a general surface given just the points at base level and some constant angle with the vertical axis? For a cone I can see that you can, but for a general surface I can´t see. Probably, I have missed some key point in some previous post, sorry.