Exo W (Ctrl+Alt+Defeat , he he)

Well friends...

... recently a fellow user initiated a thread by asking control (via attractors) on what Exo W can do :

http://www.grasshopper3d.com/forum/topics/radius-change-by-attracto...

Accidentally that was very close to some project that I have in mind (using solely C# and not components). On first sight I thought that that could be very easy ... only to discover that's not.

This definition is an over simplified version of the other mentioned (only a C# is maintained that does "preparation" work and some sort of naive "topology" checks: the yellow spheres are used as visual aids to the incompatible struts/R values combos).

You can control the 3 options available from that portion:

In a nutshell ... the Exo W behaves with an odd way (at least in my opinion). In order to get the gist of the issue stick to that portion of the def and forget the rest:

This portion of the def attempts to create an usual Exo mesh using a Line list (cleaned and user controlled as regard the min length) derived from exploded mini voronoi (i.e. brep edges). OK, I can understand the red Exo since due to the nature of voronoi breps there's more than possible the presence of small "struts" that may yield non manifold topologies.

But ... the thing is that Exo W is also red in the other mode (non Voronoi) where struts are quite big and no potential "engulfed" situations may occur:

And when the 2d Gate mode is set to Envelope ... there's cases (R values) where Exo W works as expected and cases that it doesn't.

Anyway ... if anyone has any bright idea, drop a world

best, Peter

Attachments:

Variable_thicken_with_ExoW_V1.gh, 92 KB

Replies to This Discussion

Permalink Reply by David Rutten on February 25, 2015 at 2:05pm

Is this a question about the Exo Wireframe plugin? or about Grasshopper bugs? Or about some C# code?

I don't have the three plugins installed needed to open the file successfully, so I figured I'd ask first before I go through the trouble.

Also, if a component is red, that means there's an error. What's the error?

Permalink Reply by peter fotiadis on February 25, 2015 at 11:55pm

Well ... I think that's an Exo W "bug" but it's hard to tell 100%.

I posted this here since there's a far bigger audience than in the plug-in related Forum (maybe it's something obvious/addressed somehow already by some other user etc etc).

Forget the C# (that does absolutely nothing special/clever at all: it just cleans duplicates, displays the yellow spheres in suspicious areas (i.e. small struts and "big" radii - relatively speaking), calculates the distances from the attractor(s) and finally does a classic remap work withing the "bound" limits specified - min/max radii).

By assuming(?) that it's an Exo "bug": The Exo W errors fall in 2 categories:

(a) one or more "struts" (i.e. the Lines from the exploded brep edges and/or lines provided by the proximity component) is engulfed ...: meaning (I guess) that within a given N "node" tubes from an X Line "overlap" (contain so to speak) tubes from an Y Line. However this shouldn't be the case when the proximity option is used where big "struts" are around with relatively quite small "tube" radii.

(b) object reference not set to an instance ... meaning that some List/Tree is not created (probably due to (a)) and thus flow is interrupted.

PS: Using Topologizer as a node/strut topology "organizer" before the Exo W doesn't make any difference.

RSS