Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External geometry constraints are shifted #68

Open
ceremcem opened this issue Sep 7, 2018 · 4 comments
Open

External geometry constraints are shifted #68

ceremcem opened this issue Sep 7, 2018 · 4 comments
Labels

Comments

@ceremcem
Copy link
Collaborator

ceremcem commented Sep 7, 2018

I created a Binder for rpi model in order to use its edges as constraints to modify socket-cuts, just like previous operation, but I'm having trouble with its coordinate system:

external-geometry-shifts

Project: case-v3 (copy 1).zip

@ceremcem
Copy link
Collaborator Author

ceremcem commented Sep 7, 2018

I digged a bit, here is the current experiment, which I guess Sync placement option seems not to cover external geometry constraints:

shift-explained

When Sync placement is enabled, movement of rpi-binder stays in the same position between container changes, but external geometry constraints are placed as if Sync placement option is disabled.

@realthunder
Copy link
Owner

The ShapeBinder is in PartDesign for a good reason, because PartDesign helps you manage the coordinate space. Every feature under the body is nicely inside the same coordinate space, defined by the body and all its parent container. If you want to reference something outside the body, you use binder to bring it into the body. If you moved body to another container, you resync the binder to update its relative reference.

If you want to use binder outside PartDesign like what you are doing now, you first need to have a very thorough understanding of how coordinate space is implemented in FC, which I now think is probably too demanding for an end-user. So I would suggest you revisit my tutorial and check out the PartDesign approach. On the other hand, who knows, maybe you may find other problems with that approach. All this cross coordinate space modeling is new to FC.

@ceremcem
Copy link
Collaborator Author

ceremcem commented Sep 7, 2018

This kind of operations is - I guess - the last thing I need to manage for handling any kind of drill/cut operations regarding to the assembly.

Here is my current workaround:

  • Disable Sync placement
  • Create Binder(s), drag and drop into the root of the document, see they are "jumped" in the global coordinate system
  • Put an external reference point
  • Create a rectangular, coincident its vertex to the reference point, close the sketch, "Extrude" it to create a solid
  • Sync placement can be enabled now.
  • Precisely locate the Extrude to the "correct" position by using available constraints (tmp_operation_1).
  • Delete the constraints in tmp_operation_1
  • Edit the sketch under the Extrude.

external-geometry-shift-workaround

Every feature under the body is nicely inside the same coordinate space, defined by the body and all its parent container.

Now I got why and how the previous attempt was successful and this is different (despite of Sync placement). Similarly, this is also why you suggest sticking PartDesign section of Modeling with assembly tutorial.

All this cross coordinate space modeling is new to FC.

If you think this should be completely doable and a useful feature, I can stick with my current workaround for now.

@realthunder
Copy link
Owner

This workaround seems convoluted. I would not suggest doing like that. Using binder outside PartDesign is already difficult, mixing them is near impossible I'll say. Notice the Part WB approach in my tutorial, I purposefully avoid create any model using PartDesign. Because if there is any body inside the document, new binder will be created inside that body, and all its binding reference will be relatively to the owner body. When you drag out the binder, the first thing you need to do is resync binder's reference. And if you move the binder, then you need to resync it again.

Anyway, I think the non-PartDesign approach is too complex to use in your example here. You will need multiple levels of binder to make work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants