Items in list change indices

Hi guys,

I have noticed a strange behavior with masking items from a tree or a single list. If the number of items in this list is dynamic, or if the tree/list is composed of geometry that is suffering some kind of motion, the captured geometry is changing its relative positions within that tree/list making it very hard if not impossible to mask items in said tree/list.

To give you an example I have an offset surface on a plane that undergoes rotation compared to the original surface. The vertices of these surfaces are captured with DeBrep component and connected to the other vertices with a Line component. After a certain degree of rotation the points get placed in another branch, or acquire another index. Naturally, the lines are now drawn in an undesirable way. By reducing the degree of rotation everything goes back to normal.

Am I doing something wrong here? Maybe there's a way to get around this?

All the best,

Replies to This Discussion

Permalink Reply by peter fotiadis on March 6, 2015 at 11:56pm

Hi Aristo:

where's the hot stuff? (definition/data/something/anything)

Permalink Reply by Aristo Compasso on March 7, 2015 at 12:29pm

Hello Peter.

Here's the .gh for your viewing pleasure.

I've added comments to guide the reading of the definition and to locate the problem easily.

The definition seems longer than what it needs, but to get around the double projection issue it is the shortest one I came up with to get the job done. Optimization suggestions are always welcome.

Thanks

Attachments:

RotaryBur.gh, 39 KB

Permalink Reply by peter fotiadis on March 8, 2015 at 5:27am

Er ... viewing pleasure for sure, he he (wires make me crazy/dizzy I confess, he he).

Let's start from the middle in this thing: your stuff is deactivated > play with the rot sliders provided in the freaky (C#) thing and don't blame GH (see 1:1 correspondence in points etc etc).

What was the fault? Well hard to tell (difficult to navigate across all that ... er ... stuff) but the main point is that GH works 100% correctly (that's expected: very basic things here).

Notify if you want to finish this (but using solely freaky stuff) and/or to replace all these with one freaky thing - I have some extra weird ideas related with paranoid helical (or not) gears, he he.

take care, best, Peter

Attachments:

RotaryBur_V1.gh, 57 KB

Permalink Reply by Aristo Compasso on March 9, 2015 at 3:51am

Hi Peter, thanks for your help with that "freaky" C# scripting. I'm definitely interested in understanding a little bit better the scripting capabilities in GH.

Although helpful for a number of other reasons, the problem persists.

I wouldn't call it a bug, maybe a less mature, less developed feature of GH or using a component for a purpose it wasn't devised for, only because it is the only one there.

The problem is in fact the Project Curve onto Brep component.

> the projections DO interact with the position of the seam of the Brep surface when you are projecting from the inside of a closed or wrapped around surface.

> changing the relative position between projected curve and seam results in the curves shifting/swapping their indices.

> masking out the unwanted double projection is then very difficult to attain when you set parameters that influence the previous point.

> the issue is manageable only with a couple of curves, because you have to keep track of the new indices and rewrite the mask accordingly every time you change the input parameters.

>unless something critical is escaping me, I'd say this is an area to improve in GH, either by reformulating the Project Crv onto Brep component, or creating another component specifically for inside/cylindrical/spherical projections.

Perhaps this wouldn't be a problem if one resorts to the "freaky" approach, and I'll have to force myself to learn the scripting, but my point is that this should be a really simple task merely by resorting to the component approach.

All da best,

Permalink Reply by peter fotiadis on March 9, 2015 at 4:20am

Hmm ... C# is one way ticket to hell (but if you insist ...)

OK, here's the deal of the day: provide some sketch about these #$%#$ gears of yours and I'll do it entirely the freaky way > then we can see if there's a case to complain.

BTW: As I said I didn't spend too much time digging into your def (too complicated for my primitive mind: all these ... hmm ... cables, he he) but you use project C to B for defining heli gears rails?? (Anyway, there's N ways to skin a cat).

That said I NEVER experienced such "swift" phenomena ... but I'm using solely freaky methods to do my defs these days, he he

best, P

Permalink Reply by Pieter Segeren on March 9, 2015 at 5:13am

Hi Aristo, I tried to follow your logic (hope I understood correctly), and think the way to avoid the trouble you're experiencing is to use the Twist component (from Dale Fugiers Jackalope plugin).

Attachments:

RotaryBur_PSG.gh, 41 KB

Permalink Reply by Aristo Compasso on March 7, 2015 at 12:49pm

Just to be clear, the problem I presented in the first post occurred in an earlier version of the file I have attached, where I was projecting all the lines at the same time. This file is already a work around that problem, where I project only 4 lines to make masking easy.

Permalink Reply by Aristo Compasso on March 9, 2015 at 6:25am

Hello Pieter,

I was unaware of the Jackalope plugin. It works great for the cylinder tip single cut bur and analogous twisting operations! I hope it can deliver when it comes to the actual model I'm trying to reproduce, the flame tip double cut bur.

Peter (Fotiadis) you wanna try the flame tip the freaky way? hehe B-)

I think I will try C# scripting. I sometimes do VBA for solidworks macros, but I really think C# for GH is the next level.

Thanks both. All the best.

Permalink Reply by peter fotiadis on March 9, 2015 at 8:07am

But ... a fellow user asked something similar (topologically) with that tool tip recently (he wanted to apply "balloons" (pos/neg) on divided surfaces) and I did a freaky thing for him.

What was the case? What was user's name? What was the C# name? What was the date? What was the decade?

Good questions (I suspect advancing Alzheimer)

Permalink Reply by Aristo Compasso on March 10, 2015 at 5:24pm

Yes I saw that thread... I will revisit that approach, in the mean time, I'll try and develop my own freaky stuff. Is there any repository of good practices, any sort of manual specific to C# in Grasshopper? I gather the GH primer only discusses VB and other resources made for C# are of a more generic nature. One way ticket to hell coming up!

Permalink Reply by peter fotiadis on March 11, 2015 at 12:57am

How to go to hell (and stay there) in just 123 easy steps:

Step 1: get the cookies

The bible PlanA: C# In depth (Jon Skeet).

The bible PlanB: C# Step by step (John Sharp).

The bible PlanC: C# 5.0 (J/B Albahari) > my favorite

The reference: C# Language specs ECMA-334

The candidates:

C# Fundamentals (Nakov/Kolev & Co)

C# Head First (Stellman/Greene)

C# Language (Jones)

Step 2: read the cookies (computer OFF)