Rigid group captures the wrong information in the timeline

Rigid group captures the wrong information in the timeline

ltomuta
Advisor Advisor
303 Views
3 Replies
Message 1 of 4

Rigid group captures the wrong information in the timeline

ltomuta
Advisor
Advisor

I have a component that contains a linear pattern which parametrically controls how many subcomponents are created.
Following the pattern, the timeline contains a "Rigid group" that includes among other components the parent and also has the "Include Child Component" option.

The expectation is that no matter how many children are created through the pattern they are all included in the rigid group. But in fact, the rigid group does not store the "include child components" option but the actual hardcoded list of children existing at the moment of the rigid group creation. Which means that if the number of children changes at some later time, the rigid group does not reflect that fact.
ltomuta_0-1716879961432.png

 

0 Likes
304 Views
3 Replies
Replies (3)
Message 2 of 4

Drewpan
Advisor
Advisor

Hi,

 

Without seeing the actual model file, what you have explained seems to make perfect sense.

 

The children are being created by the parametric input and grouped at the same time. The only children that fusion

knows about are the ones you just created. How does fusion know if you create more children in the future to link

them to this rigid group? If you want to add more components to a group it is a new item on the timeline. If you wind

the timeline back, change the parameters then a new set of children will be created based on those parameters and

will be grouped because that is the only thing fusion "knows" about. Any more components you add to this group

should be added by the new timeline entry when you wind the timeline back to the end.

 

The children are created by the parameter. If you change the parameter without moving the timeline back then it

"should" create more children but there should also be a new entry in the timeline, fusion will not automagically wind

back the timeline, fix the group and wind the timeline back - you do that.

 

The timeline is exactly that -  a time line. If you create something in the past then it cannot forsee the future, even if

the future exists because the timeline is not designed that way. Where the timeline is is what fusion knows and

calculates. Move the timeline forward and it re-calculatess because it now knows more. All of the stuff in the future is

what fusion stores and uses to re-calculate as the timeline advances. This is why it is sometimes critical to fix yellow

and red items in the timeline as they happen because they can break the model so badly later with bad data.

 

It seems to be doing what is on the box. I know this right now and I can calculate it. If you change the parameter

I will step through the timeline and re-calculate everything then add this new bit you have just changed but I am

adding (or subtracting) it when you tell me to. If the change is not compatible with what I know I will throw a red or

yellow warning.

 

Cheers

 

Andrew

0 Likes
Message 3 of 4

ltomuta
Advisor
Advisor

How does Fusion know that I now want that the pattern should now produce 5 instances of a feature instead of 3? It does not.

What Fusion does know is that the value of a user parameter was changed so it goes back in time, finds all the timeline items affected by the change and re-computes them. It finds a pattern feature controlled by the parameter, it updates that. The result, more or fewer instances of the patterned feature/component. It's what the Compute All does. Automagically.

If that would not be the case, a "parameter change" feature would be captured in the timeline and the new parameter value would have effect only from the time of change onwards.

The problem is that Compute All breaks when it evaluates the next feature on the timeline, i.e. the rigid group, because this feature does not store the correct input. For if the input would be "component X" and "all component X's children" then Compute All could figure out that since X has now a change in the number of children as a result of the re-evaluation of the Pattern then the rigid group feature should be updated as well and the current children of X would be grouped.

0 Likes
Message 4 of 4

laughingcreek
Mentor
Mentor

what you're describing is an on going complaint about about how component patterns and rigid groups work.

 

a recent update has somewhat alleviated this particular pattern issue by automatically grounding newly created components to their parent.  (if your file was created before the update you may have to start a new one to see this, IDK how backward compatibility was handled). 

0 Likes