A smarter way of doing this - Crash detection

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,

Charles

Attachments:

Simplified Nodecrash solver.gh, 17 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on April 22, 2015 at 10:28am

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?).

Permalink Reply by Alex Bodkin on April 22, 2015 at 10:37am

Hey,

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.

Attachments:

dead end strut.jpg, 180 KB

Permalink Reply by peter fotiadis on April 22, 2015 at 10:41am

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).

Permalink Reply by Alex Bodkin on April 22, 2015 at 10:50am

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

Permalink Reply by peter fotiadis on April 23, 2015 at 1:15am

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)

Permalink Reply by Alex Bodkin on April 23, 2015 at 6:43am

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?

Permalink Reply by peter fotiadis on April 24, 2015 at 12:18am

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).

Permalink Reply by peter fotiadis on April 24, 2015 at 2:14am

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).

Permalink Reply by Charles Fried on April 24, 2015 at 8:54am

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 :)

Attachments:

Wireframe.3dm, 64 KB

Permalink Reply by peter fotiadis on April 24, 2015 at 9:55am

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

Permalink Reply by peter fotiadis on April 24, 2015 at 10:42am

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)

Permalink Reply by peter fotiadis on April 24, 2015 at 11:12am

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: