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):
PS: Haven’t checked your stuff … but I do hope that you calculate the first “up next” 2 points “per next Layer” since we are talking revolved Surfaces. I mean these points:
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.
Refer ro the sketch attached some replies ago (with the 2 magenta Circles and the candidate Cyan: the one that is fixed if we can find X).
Since we are talking about revolved Surfaces FORGET the Surface (i.e. never do it) and stick to things that matter: the Profile and the Circles. The only difference VS the cone is the White lines: Let’s talk about the first one: the From point is the Profile start Point. For the other we advance - or we do ccx Plane/Curve - some t value (within a loop with some step) that yields a point (at Profile.PointAt(t) ) that defines d (a given), the next Cicle, the delta (diff between the radii) and obviously the next point at the Circle (P [1] (1) in the sketch). That point is “fixed” (see the trigo equations posted) accodring your division value and the next Circle R.
Then we measure the half angle and this is the static LBS angle for the next steps.
Then … well … is about a loop where we search a X (having as quideline the previous d) that yields the very same angle (within tolerance). This loop (done via recursion) is a classic bounce search where the step is variable and more and more becomes smaller in order to find the value desired. But … I barely have any idea how to do it via components.
Now … you may think that this way is a bit complex and appears to be kinda the bazooka and the mosquito case … but guess what? Yields results 10++ times faster than Cone/Cone ccx events. If you have 200 layers … well … that’s the difference between 2 and 2000++ milliseconds (that’s half the story but you get the gist of my meaning I do hope).
All that said … If I may give you an advice, is this: learn how to code ASAP (the only way to become a pro on high demand in the years to come).
PS: Unless you are after some tensegrity solution (where the black/blue are cables) I would strongly suggest this:
Yesterday 2 fellas from a certain US Agency contacted me and asked an egg like exoskeleton residential tower with variable floor heights (hard to imagine the reason, mind, but they pay tax free dollars). This means that I must add 10 lines more in the conic C# in order to work with any revolved Surface (any Profile in fact, forget the Surface).
