Pattern on Path, "Origin" of component messes it up

Pattern on Path, "Origin" of component messes it up

kevin_trefflich2
Participant Participant
2,197 Views
28 Replies
Message 1 of 29

Pattern on Path, "Origin" of component messes it up

kevin_trefflich2
Participant
Participant

Hey,

I´ve included a screencast with spoken explanation where I describe my problem. It´s best you watch this, easier than writing it all.

https://screencast.autodesk.com/Embed/Timeline/8b04edcb-14ed-496b-9d2d-8ff4adc0c684

 

Shortform in text:

I need to create a pattern of a component along a curved line from a sketch. Problem is that the components do not follow the path perfectly. From what I can figure this is due to the "origin" of the compenent being vertically offset and not in line with the path. I suspect this is because the compenent is not perfectly symmetric along this axis.

To test this I have recreated the component in its most basic dimension but made it symmetrical, the "origin" of this compenent is now in line with the path. If I use this component to create the pattern everything lines up perfectly.

 

The question is how do I fix this, can I move the "origin" of the component somehow?

For clarification the actual origin of the part (the one that you can choose via the the list of the components on the left) actually is in line  with the path. Only the "origin" that is displayed when I choose to move the component is offset.

 

Thanks for your help

 
 
 
0 Likes
2,198 Views
28 Replies
Replies (28)
Message 21 of 29

kevin_trefflich2
Participant
Participant

I sincerely disagree.

You´re workaround is sadly not sufficient because as shown in your picture, the chain extends further to the left than it would in reality. I can´t give a file to a client where the chain is clipping through other components and say that its just this way because I coundt figure out a way how to model it correctly.

 

In my honest opinion there is either a bug in the implementation or we all don´t really understand how "pattern on path" is supposed to work.

 

What I think it would do is:

1. Place Points along the path with the given spacing

2. Create a tangent to the path for every point

3. Look at the first point and its tangent on the path

4. look at the first object that is to be replicated and where it is placed

5. figure out the relation between this first object and the the first tangent from step 3 (how far away and on which angle is the object placed in realtion to this tangent

6. align all the replicated objects the exact same way to their respective tangents.

 

This method works however the first object is placed in relation to the starting point and if this is how pattern on a path works internally, this should work in my usecase as well.

 

To prove this I have repeated this methodology manually with my cable chain.

1) I manually created sketch-points along my path using the old formula for the length of an arcsegment given the radius and the angle from school

2) I drew in the tangent to the first point, a simple horizontal line that is colinear with the horizontal bottom part of the chain

3) I placed the first chain element where it is supposed to go

4) As is happens the first point is exactly aligned with the midpoint of the line connecting the hole and the stud of the chain element (obviously this is exactly what is supposed to happen)

5) For each point along the arc I created a Joint Origin on said point that is also tangential to it.

6) I manually copy the chain elements and, using the align tool, place the midpoint of the line between the hole and the stud on the respective Joint Origin. This aligns their position and rotation the exact same way as the first element is aligned to its respective tangent.

 

As it turns out, the result is flawless. The ends of the chain line up perfectly and the elements follow the sketch nicely. It is also almost identical to the step file. Along the curved section the holes and studs of the elements dont line up absolutly perfectly but that doesnt matter. They show about the same deviation from one another as is the case when I use my method shown in my original post with a symmetric cable chain.

 

In the attachments you will find this file to look for yourself.

 

This proves to me that either my understanding of how "pattern on a path" works is incorrect or there is a bug in its implementation. So this is where we stand.

0 Likes
Message 22 of 29

TrippyLighting
Consultant
Consultant

@kevin_trefflich2 wrote:

...

 

This proves to me that either my understanding of how "pattern on a path" works is incorrect or ...


Probably 😉

 

I find it somewhat remarkable that no one has observed what governs that behavior. Granted , having that info part of the documentation would be very nice, but I can always summon @Phil.E @jeff_strater or @jodom4 to confirm the behavior and perhaps contact the right folks within Autodesk to add it to the documentation.

 

Based on my experiments in the attached file, I would observe that at least for the component pattern I used there, Fusion 360 uses the center of the bounding box around the geometry in the component as the center point for the pattern.

 

If you change the "offset" parameter, you'll see that the origin of the chain link component can be pushed outside of the geometry, but that does not appear to make any difference on the pattern location.

 

The lower right pattern is a "blob" and there, changing any of the three main radii changes the location of the geometry in reference to the components origin, but the center of the pattern remains to be the center of the bounding box so location of the pattern on the path remains the same.

  

 

TrippyLighting_0-1651675468817.png

 


EESignature

Message 23 of 29

johan.rutgeerts
Advocate
Advocate

@kevin_trefflich2 wrote:

In my honest opinion there is either a bug in the implementation or we all don´t really understand how "pattern on path" is supposed to work.

 

I had another look at your screencast. 

 

I haven't been able to reproduce your issue; for me it works exactly as I described in this post.

File in attachment.

 

Case 1: start of trajectory at the front of the link:

johanrutgeerts_0-1651677075760.png

Yields this result, as expected:

johanrutgeerts_1-1651677215847.png

 

Case 2:

Start of the trajectory at the center:

johanrutgeerts_3-1651677301053.png

 

Yields this result, also as expected:

johanrutgeerts_4-1651677375432.png

 

 

I think it is indeed a bug, and probably related to the weird 'start point' behavior.

In your case, start point is for some reason initially set to a non-zero value and you set it to zero, whereas in my case it is initially already zero.

 

 

Regards,

Johan

 

0 Likes
Message 24 of 29

kevin_trefflich2
Participant
Participant

@TrippyLighting 

I can confirm this, Fusion is using the center of the bounding box as it´s origin.First Element.JPG

The center of the bounding box is offset by 4.95mm to the starting point of the path in the X direction.

Using my method described in the original post an element that is placed along the arc will look like this:

Element on Arc.JPG

It´s beeing offset the same 4.95mm to the left.

 

But still, I consider this a bug.

The offset is strictly applied in the x direction but it should be applied along the path. 

Granting the bounding box is beeing used as the origin, I would expect this behaviour if you choose "Orientation: Identical" because then the objects won´t get rotated and since the offset of the first object is strictly in the X direction it also is for all duplicated objects.

But when I choose "Orientation: Path Direction" I would assume the offset beeing applied along the direction of the path, this would solve my problem.

It seems to me that it was forgotten or not thought about in the implementation. Maybe we can get some developers opinion on this.

 

Nevermind the "bug", knowing it uses the bounding box I can use a workaround for my usecase. I can simply just "cut" away from the chain element so that the center of the resulting bounding box aligns with the midpoint between the hole and the stud of the element. Cutting away a little piece is fine in my case because it is on the insede of the chain and nobody will notice it and I can achieve my goal in showing outer dimensions of the chain for every position it can be in.

 

Thanks for all your help.

Again, maybe someone from autodesk can look into this and tell us if this was an oversight or desired behaviour.

 

0 Likes
Message 25 of 29

johan.rutgeerts
Advocate
Advocate

@TrippyLighting @kevin_trefflich2

I still don't see why in my file exactly the same relative position of component wrt origin of trajectory leads to this result:

johanrutgeerts_0-1651683899258.png

 

Whereas in @kevin_trefflich2 's file it leads to this result:

johanrutgeerts_1-1651684005644.png

 

 

 

0 Likes
Message 26 of 29

kevin_trefflich2
Participant
Participant

Mh, thats weird.
I´ve been playing around with your file, even creating the sketch again and it works.

I figured out that its because you didn´t break the link of the chain element.
I created a new test file where I once imported a chain element and left the link intact. This one works perfectly.
Then I imported the same element, from the same file but broke the link after importing. After doing everything else the same (lining the element up with the starting point of the path etc) the elements are duplicated the wrong way just as shown in my first post. I even used the exact same sketch as the path in both scenarios with exact same settings.


I really don´t get why this would make a difference, kinda speechless at the moment to be honest.

This thing gets weirder every day.

Thanks for your help

0 Likes
Message 27 of 29

johan.rutgeerts
Advocate
Advocate

@kevin_trefflich2 wrote:


Then I imported the same element, from the same file but broke the link after importing. After doing everything else the same (lining the element up with the starting point of the path etc) the elements are duplicated the wrong way just as shown in my first post.

 

I can confirm this. Delete the correct pattern, break the link, recreate the pattern and the new pattern is incorrect.

 

What I notice is the following:

 

Initially, when the component still has its external link and you create the pattern on path, the dialog box shows 0 for both Distance and Start Point:

 

johanrutgeerts_2-1651696449670.png

 

When you then set the parameters to their desired values, the resulting pattern is correct:

 

johanrutgeerts_3-1651696587705.png

 

 

However when you break the external reference, and then do exactly the same, the dialog box initially shows 4.95mm and 0.005 for Distance and Start Point:

 

johanrutgeerts_1-1651696372505.png

The resulting pattern is incorrect.

 

 

@jeff_strater we have an elaborate problem description, example files and reproducible behavior. Can someone either explain this behavior, or file this as a bug?

Furthermore, and insofar not related: why does changing the Start Point change the pitch? See below pictures:

 

johanrutgeerts_6-1651697411831.pngjohanrutgeerts_7-1651697443683.png

 

 

 

Thank you,

Johan

 

 

 

Message 28 of 29

johan.rutgeerts
Advocate
Advocate

@jeff_strater @Phil.E 

 

 

@kevin_trefflich2  I needed to model another chain, which unfortunately gave me the same issue. However I found a workaround:

 

To recapitulate the issue first:

 

  • When creating a new 'pattern on path', it should show zero for distance and start point:
    johanrutgeerts_1-1653077023016.png

     

  • However sometimes (*) it shows values instead of zero:
    johanrutgeerts_4-1653077980512.png

     

If the values are non-zero, you need to set them to zero manually, but than then the geometry is off wrt the trajectory by that distance. It seems your conclusion that this is related to the center of the bounding box is correct (**):
johanrutgeerts_5-1653079280777.png

 



The workaround is simple: shorten the path with that amount and redefine the pattern:

johanrutgeerts_6-1653079439640.png

Result:

johanrutgeerts_7-1653079541343.png

 

 

 

 

 

Further remarks:

 

(*) It is not clear to me what causes this. As you mentioned in the previous posts: breaking an external link can trigger this, but I have also had this issue without breaking the external link.

 

(**) The strange thing is: when it works correctly (i.e. values are zero from the start) than it seems that the center of the bounding box is not relevant, but instead the relative pose of the component wrt the initial point of the trajectory is transformed (which is how it should be):

 

johanrutgeerts_8-1653079867672.png

 


Regards,

Johan

 

 

 

 

 

 

 

Message 29 of 29

Phil.E
Autodesk
Autodesk

Thanks. I've sent a link to this post to the modeling team that is working on pattern as information for their efforts.





Phil Eichmiller
Software Engineer
Quality Assurance
Autodesk, Inc.