A smarter way of doing this - Crash detection

by Charles Fried

Apr 10, 2015

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

  • up

    peter fotiadis

    Use trigonometry:

    Lets call the cylinders shown "struts" (actually they are strut adapters if you use a MERO type of space frame).

    1. First and most importantly you need a faultless way to get connectivity data (in mesh cases: SandBox comes in mind but it fails in quite a few occasions especially when non manifold meshes are used).

    2. Then and based on connectivity data  compute the diagonal between each pair of strut axis. Then rStrut/strutLength = Math.Tan(diagonalAngle/2.0). Where rStrut = strut radius, strutLength = the length to compute. See this where Lengths are constantly variable depending on the diagonals/2.0 per axis pairs.

    BTW: this shown does the "inverse" thing (VS a MERO): creates adapter nodes on a per node basis (made as one-off via 3d-printing) ... but the gist of the method is quite clear (I hope)

    12

    Apr 10, 2015

    Load Previous Replies
    • up

      peter fotiadis

      Matrix reloaded (via Plan C: the black pill):

      Here's a greatly reduced (300 lines VS 1200+ of the real thing) C# "truss out of lines" thingy for you.

      1. 4 node modes (3 of them are related with modular nodes).

      2. The 4th "liquid node" mode is (obviously) related with that "temperamental" ExoW thingy: due to that I've set up the related output on a per node basis > first exploit what's possible with Exo (and adjust the variables accordingly) and then ... fire and forget.Not all topologies yield return something worth looking mind:

      3. The other modes are straight stuff (always doable)... so all nodes are created at once.

      4. Load Rhino file first for the demo test data.

      5. I've reworked the functions by removing LINQ and other weird stuff ... in order to allow you to follow what's happening with the most "palatable" way. This means that several portions of the code are ... er ... a bit stone age, he he.

      6. I strongly recommend the modular node design: simpler, faster and always doable (note that protrusions are the other way round allowing to use hollow tube struts ... instead of struts + some insert adapter)

      best, Peter

      18

      Apr 16, 2015

      Load Previous Replies
      • up

        Charles Fried

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

        4

        Apr 24, 2015

        Load Previous Replies