Please fidget with the red sliders.
For some reason, the loft spontaneously blinks out!
It happens unexpectedly, and somewhat unpredictably, whenever you either:
A. Add (or subtract) from the x value. (It does not happen with y or z! Why is this?!)
or
B. Change the number of longitudes. (In a different file, I ended up with only the even numbers working, and in yet another context, nothing worked.)
If x+ is VERY close to zero, then the # of longitudes doesn’t matter.
But if you add much value to x+ , then the # of longitudes becomes ‘hit or miss’.
Also, although it is not highlighted, the radius affects the blinking as well; if you increase the radius enough, ‘unfavorable’ conditions (Loft out) are suddenly ‘superceded’.
Yes, I understand that concept.
However, I would like to preserve the coordinates of the points for further manipulation.
Why does the zero-length (or a point) curve only blink out under certain manipulations?
Or, to put it oppositionally, why does it work without issue under certain conditions?
I don’t know for sure, but it certainly has to do with your last curve to loft being of zero-length.
Just try and remove it! It resolves the issue.
Maybe the Loft component realises that and does something to remedy the situation which then fails from time to time? It’s hard to tell what exactly happens inside the components.
You can still do that. The coordinates aren’t lost!
I like the removal of the offending curve method, but how do I get rid of the hole? Is it possible to have the loft converge to a single point? In place of the ‘non-curve’ consisting of multiple equivalent points?
In my opinion, the revolution surface or mesh, one of both is the way to go forward. You can pretty much do everything with those two, even if you can’t imagine it yet.
The benefits of the surface are that it has very precise curvature information, whereas the mesh even with a very high resolution is just an approximation of the “perfect” dome.
The mesh on the other hand is much lighter and can be easily manipulated as long as it has a low polygon count. It can also be directly used with Kangaroo and easily exported with clean topology to other mesh modelling apps, where as the surface would have to be triangulated or quad remeshed first.
I’ve had the same sort of problem when designing shapes for 3D printing. What I did was give the top circle a tiny radius - like 0.01 or 0.005 (millimeters). This worked for me because when 3D printing a radius that small is effectively zero.
Yes, a last resort.
I’d like to avoid this needless complexity, as it seems to work absolutely perfectly under similar conditions to those in which it fails entirely.
How hard is it? Not impossibly hard, I presume.
I’d like to see exactly what’s taking place inside the components, if we may, so that I can preserve this oft-flawless functionality without mucking up the definition. How may we go about doing this?
You’d have to hack/de-compile the component in question - which probably is illegal - with appropriate software, learn C# as well as the Rhino API - if you aren’t privy already - to understand the unraveled component code, and rewrite/retro-engineer/copy/pirate the code for your new component and (re)compile it, because with real code you can do much more than with vanilla Grasshopper components. Don’t get me wrong! Many wonderful things can be achieved with the components, but with coding the real magic happens. And no, I personally don’t view vanilla Grasshopper usage as scripting or coding.
