algorithmic modeling for Rhino

Hi there,

I'm getting close to finalizing my node definition.

One of the last steps is to optimize the position of each node so that they are as close in to the center point as possible. This in order minimize printing cost and avoid mesh issues when they collide.

I've made an initial definition which does want I want but is not accurate nor recursive, it simply moves forward once by a given value if it collides.

Is there a more accurate way of doing this? Ideally setting a distance between each rod and working out the placement according to this, perhaps using a solver?

Thanks in advance,


Views: 5274


Replies to This Discussion

Hi Alex

Indeed points connected with just one point yield an exception since ... er... the whole thing is written with triangulation in mind.

I'll add an ignore "singular" struts option soon (but has this any meaning? I mean since such struts they would be ignored ... why sample them in the collection anyway?).


I've attached an image of the situation that I tried to describe. Hopefully this is more clear! :)

As you can see, there is one "single"/"dead end" strut plugging into a network of "connected" struts.

the "single" strut must be sampled in the collection because it is still connected to other struts at one of its ends.


Well, I've understood the issue quite clearly ... my (rhetoric) question was related with the reason to include such strut(s) in the List of struts to be processed.

I mean, yes it's (obviously) connected but so what? (since the solution would be performed WITHOUT similar struts).

Ah, I'm sorry, I don't think I quite understand. 

Not sure why you can't understand the simple question: WHY sample "singular" struts that WILL ALWAYS been excluded from the solution.

Anyway ... it's very easy to "clean" the eList: this is what you need? (green = singular struts that are excluded from calculations/solution)

Hi Peter,

Thanks for taking the time to go over this, I really appreciate it.

In your image, the pink struts are connected to the node joints, but the green/singular struts are not connected. Is it possible to also connect the green/singular struts to the node joints?

Indeed this requires some rethinking/rework:

3 Modes: (a) ignore singular strut, (b) make singular strut, (c) make ONLY the related adapter. (thus the singular line acts as a direction guideline).

(c) IS the most important of them all: allows you to place "special" [non strictly truss related] adapters that support all the rest (from facades and roofs to furniture related stuff etc etc).

BTW: Done (but needs some finishing touches more: that's the mouse trap with code > what if I add this/that/or this?).

Still (case: include singular strut) it doesn't make any sense to me: it's a "bit" unstable or what?

BTW: Sequence contains no elements (+ red alert + Armageddon) was due to that line highlighted (nothing to do with physical intersections: it has to do with the find common items between Lists thingy). No filter was added to prevent that ... because the case of singular strut haven't crossed my mind (but appears that it has some meaning: 3rd option).

Hi Peter,

I'm having problem with these two wire frames, they seem to cause sandbox to fail every time.

Is there anything I can look out for that could be causing this issue?

As I understand it as long as these are closed poly-lines it should work...

Thanks :)


Hi Charles,

As I said Sandbox behaves strangely on some occasions (this is the reason that the pro AEC version[MERO and the likes] uses my connectivity(C)(tm)(US patent pending) algorithm by-passing completely Sandbox).

NOTE: use ONLY lines NOT polylines > break them all into segments, no mercy.

NOTE: I'll add a check capability for duplicates (s@#@$t happens all the times, he he) and/or polylines and/or cats/dogs (we accept anything provided that is a single Line , he he).

I'll investigate this case or yours ASAP ... but since a fellow user asked a "dead-end" ("free" singular struts) capability ... I've completely reworked the whole thingy (way better in every aspect : 0.001% faster, more bugs, more divisions by zero, more chaotic options ... PLUS it allows you to use "special" adapters for mounting stuff [NOT related with the rest of the truss]).

I'll post the V4 very soon (plus your case as test).

best, Lord of Darkness

Hmm ... this IS complicated (although V4 eats similar stuff for breakfast):

1.Good news: both of your cases work.

2.VERY BAD news: due to some duplicate, some Karma, some tolerance, something anyway ... the find singular strut (new stuff) function (based on SandBox connectivity data)  reports in both cases a singular stut where there's not such thing (in fact ... there is : it's a duplicate).

3. 1M Q: Where is my C# for removing duplicates? Is it in this workstation or in another? What was the name? Why I did it? (you tell me) What about Alzheimer? (ditto)

OK, here we are:

1. At the core of the whole thingy is the new locate singular struts function. IF IT finds some then the pink options/sliders are active. IF IT finds (based on SandBox data ) whilst we assume that they are not around > Armageddon > because the new policy deals with the singular struts INDIVIDUALLY (they are NOT subject to clash detection and they have their own length variable - this happens to your faulty tests):

2. The info panel informs you about such stuff:

3. You can treat singular struts with 3 ways : ignore, include, do only the adapter (FROM the non singular node TO the singular node):

4. Same applies to the liquid option for the ExoW (BAD idea: avoid at any cost):

I hear you: but now the thing becomes ultra complex and utterly paranoid > is this progress? Yes it is, he he.

BTW: V5 with a lot of topology checks under way

BTW: Load Rhino files first.

may the Force (the Dark option) ... blah, blah







  • Add Photos
  • View All


  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service