Kangaroo 2.02 released

Replies to This Discussion

Permalink Reply by 未知 on April 29, 2015 at 11:10am

Thank you very much, add these cool features.

Permalink Reply by Anders Holden Deleuran on April 29, 2015 at 2:04pm

Excellent, sounds good. This explains why the elastica I was testing today weren't behaving as expected (i.e. they were dependent on division length). Does this mean I should just use the angle goal for bending now? Noticed that bend is still in there when going through the scripting API.

Permalink Reply by Daniel Piker on April 29, 2015 at 3:07pm

Yes, for now the angle goal is the best one to use for bending as well. I should update the actual bending goal in the API with the same correction, but didn't do that yet in this release.

Permalink Reply by Anders Holden Deleuran on April 30, 2015 at 3:08am

Thanks, no worries. Is it then correct that the direction of the two lines should be like so:

lineA.From------lineA.To/lineB.From------lineB.To

Meaning that the line segment directions along an elastica polyline would look like so:


Ps. Mario and I have been looking into some textual approaches for how to diagram/document the input parameters for making constraints (think Ascii style). This could be part of something like a docstring (I assume C# has something similar) within the goal/constraint class itself. I think I will put some time aside for this as part of my PhD. If you're interested I could sketch some ideas for Kangaroo as well?

Permalink Reply by Daniel Piker on April 30, 2015 at 4:04am

Yes, the angle is the exterior angle, so the end of the first line should be the start of the second.

About the documentation for each goal - I think including it within the code, and auto-generating docs from this is a good idea(Will was talking about something similar).

Though if you mean using ascii art geometric diagrams like this:

    /\

A/    \B

/_____\

    C

I'm not really a fan! I guess they have a kind of retro, dot-matrix-printer-era charm, but for most practical purposes I find them restrictive, unclear and awkward to create or format.

I don't know what the ideal solution is here though. For the geometric algorithms we deal with in CAD it is so often very useful to have some images alongside the code, and we really should have a good way of keeping them organized together(and ideally have the images show up along with code-completion in the IDE).

Permalink Reply by Anders Holden Deleuran on April 30, 2015 at 5:02am

Ah yes, I forgot that Will had begun to think about this.

Hehe indeed, me neither. I wonder if it even is possibly to develop a formal text-based representation which makes sense (i.e. is clear, explicit, flexible etc.). For ShapeOp it sort of made sense since the inputs are always lists of point indices and how they relate to each other (angle example here).

Images would definitely be preferable. I suppose that a first step might be to simply host images on the Git repository along with the source. One option from here might be to develop a "Goal Help" component which launches a browser opening the relevant image. Or, maybe it could even display the diagram directly in the Rhino viewport. I suppose that having a dedicated component might make maintenance easier and could also be linked to the auto-generating of docs.

Anywho, it's certainly an interesting topic :)

Permalink Reply by Ángel Linares on April 30, 2015 at 10:54am

Yeahhh! Thanks Daniel. The funniest GH related period of time I had in while. Reading the release notes.

Permalink Reply by Gwendolyn on May 1, 2015 at 12:07pm

Multi-radii sphere collision, please. :D

Permalink Reply by Ángel Linares on May 5, 2015 at 11:36am

It's actually possible with this version...you need to put together different goals but it is definitely possible :)

Permalink Reply by Gwendolyn on May 5, 2015 at 11:55am

I would love it if you would outline exactly how you'd accomplish this. I've tried playing around with Length(Line) and SolidPointCollide, but they never seem to work in the same way that SphereCollide does. :c

Permalink Reply by Gwendolyn on May 5, 2015 at 12:34pm

So, I'd still like to see what anyone else comes up with, but after looking over my own attempts I feel I should mention more precisely what I've tried...

Using ClampLength on a collection of lines Cross-Referenced (diagonal) from some points, with the Lower Limit being similarly cross-referenced for the desired radii and the Upper Limit being way high, I can get something that KIND OF works like SphereCollide with multiple radii... Except it's not very precise (it always leaves significant gaps, i.e. it doesn't seem to actually allow the lines to go as low as their lower limit) and it's very slow (much moreso than anything else I've seen in Joey!).

This is all imprecise enough that it really doesn't work at all for my desired results. I've been spoiled by the speed and precision of SphereCollide, thus why I just long for a multi-radii version of it. Or a better workaround, if anyone has one.

Permalink Reply by Ángel Linares on May 5, 2015 at 1:32pm

Here you have a possible solution. There is a goal virtually deactivated, but it's helpful in some cases. Just play with it a little bit. You will need tree-sloth in order to run it (it simplifies a lot the data matching process).

Attachments:

• Sphere_packing.gh, 581 KB