Path object model + dressups

[mlampert]

The introduction of dressups brought some interesting bugs with it and I'm wondering if folks have an opinion about how to fix those.

What happens now is that the parent of a Path::Feature object (let's say a Profile) can now be another Path::Feature object (a dressup). There can be an arbitrary amount of levels since you can dress up a path that's already been dressed up - and believe me for now, you actually want to do that.

As I see it there are 3 options:
1) create a new type like Path::FeatureDressup
2) a dressup should really be a Path::FeatureCompound with its own path, not a Path::Feature
3) a Path's parent can be another Path

Opinions, comments?

[yorik]

Hi,
A path dressup already has all the features you mention,no? (you can make a dressup of a dressup of a dressup, etc... forever)
I don't really understand what you are suggesting?

Or are you saying the path dressup should be coded in C++ instead of python? That could be done, but IMHO has little advantages, because the processing done inside the path dressup is very small, so it wouldn't make a huge difference, and it would also make it much harder to modify/extend, since it couldn't be done in python anymore.

But I might have misunderstood you, please explain better if it's the case.

[mlampert]

I guess I wasn't clear - let me try again.

You are correct that a dressup can dressup a dressup ... and all that works. What happens though is when you edit/modify the underlying, original path it can't find the job it's part on. The reason is because in PathUtils (at least) there are assumptions being made about the position of a Path in the object tree.

One of the assumptions is that the parent feature of a Path will always have a Group property. But now, if a Path is dressed up that is no longer true.

I agree with you that by removing these assumptions from the utility functions everything works as advertised, my only question is if that is what we want or if ppl prefer a different alternative.

[chrisb]

Not knowing much about the underlying structure in my view a dressup is similar to a part design feature. Like in Part design a feature can be based on a feature yielding a valid object so can in Path a dressup be based on a dressup yielding a valid path.

[sliptonic]

I guess I wasn't clear - let me try again.

You are correct that a dressup can dressup a dressup ... and all that works. What happens though is when you edit/modify the underlying, original path it can't find the job it's part on. The reason is because in PathUtils (at least) there are assumptions being made about the position of a Path in the object tree.

One of the assumptions is that the parent feature of a Path will always have a Group property. But now, if a Path is dressed up that is no longer true.

I agree with you that by removing these assumptions from the utility functions everything works as advertised, my only question is if that is what we want or if ppl prefer a different alternative.

In my opinion, the assumptions in PathUtils are incorrect and should be regarded as a bug.

[yorik]

Ok now I understand better... You mean if an underlying path changes, the position of the dressup might become wrong.

That's indeed the case, and it won't be easy to solve, I'm afraid. How can a dressup know the exact position where it must occur, besides relying on a position number? "Finding" a specific command in the underlying path could be done, but it is highly error-prone. What if there are several identical commands? What if the command to be found has changed and doesn't exist anymore? Maybe that could become an option, but my guess is that it will give as much error as the current way.

One possible way out could be a kind of placeholder system: In the underlying path, there would be a unique "placeholder" (for ex. a comment) that the dressup could detect. But even then, the positioning problem would still exist, it would simply be in the underlying path instead of the dressup.

This is really not easy to solve...

[chrisb]

So the problem is, that paths are not parametric and dressups aren't either. I see that there are theoretical questions to be answered and perhaps it boiles down to topological naming (again).
To increase meanwhile the usability, would it be possible to have something like the recompute-button in the Drawing Dimensioning WB. I think it simply redoes the steps made on creation.

BTW am I right, that none of the dreesups is workoing yet? I tried the dragknife, it creates only at one of 4 corners a dressup, and the pure dressup does nothing.

[sliptonic]

BTW am I right, that none of the dreesups is workoing yet? I tried the dragknife, it creates only at one of 4 corners a dressup, and the pure dressup does nothing.

The original dressup was just a demo to introduce the concept. It really didn't do anything useful. Now that we have some working examples, it can be removed from the install.

Drag knife should be working correctly. I've used it for real projects. If you're seeing a bug or it's not behaving as expected, please post with a file or make a bug report so I can look closer.

Mlampert is finishing up dogbone soon and it'll be another really nice example.

[chrisb]

- Cube with square pocket
- Path Pocket
- Dragknife

Expected: A square path with overshoot in at least 3 corners.
Generated: A square with one overshoot at the end.

[sliptonic]

- Cube with square pocket
- Path Pocket
- Dragknife

Expected: A square path with overshoot in at least 3 corners.
Generated: A square with one overshoot at the end.

You've applied the dressup to a pocket operation. It's generating a square path because of the size of the tool relative to the pocketed face. If the tool was smaller or the pocket bigger, the path would be concentric or zigzag lines clearing the entire face. That kind of path isn't what I had in mind when I was writing the dressup. Can you help me understand the application you had in mind for this and why you chose a pocket op instead of a profile?

I redid the same thing, profiling the face and the dressup modified all four corners as expected. I'll dig deeper into why it fails with a pocket but I'm trying to understand the use-case for such a dressup.

BTW, my last pull-request broke dragknife a bit. I'll submit a fix soon.