Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Mirrored components should update with body changes.
Right now when I mirror an component it looses it's "link" to the original compononet so when I do any changes to the body the mirrored component does not update, while obviously regular duplicated ones do.
In my mind and workflow having mirrored compononets working just like regular copied/duplicated compononets is a must.
Trippy, ofcourse you can step back with the timeline but.. if it works for regular copied components, why not mirrored, why is there a difference ? why do I have to go back in time for one and not the other ? Also you can disable the timeline, then what ? and even if you have the timeline enabled and go back to do the updates you will have to jump back and forward all the time to see the updates.
So I still think it should still just work like regular copies, because in my mind I thought about the timeline before making this suggestion 🙂
To the extent that rolling back in time is the «correct» solution, it's not remotely obvious to me and I can't see why moving forward should break any symmetry (unless the user explicitly does something to break them)
While I don't disagree in general, it is easy to see why it was implemented the way it currently is.
The problem to solve with mirroring a component is not at all trivial.
Keepin associativity between instances of components, such when copy/pastin is a much, much simpler problem to sove.
When playing around with this it is very easy to see what the difference is between copy/pase component and between a mirrored component. A copy/pase component instance, for example contains the skech that was used to create the component. It is also simply an instance of the same sketch. Every object and feature in a copy/pasted component instance is a link back to the object in the original component.
That is not such an easy thing with mirrored components. Imagine a componet is mirrored twice, say once around the X and another time raound the Y axis. Attempting to keep associativity is much more diffcult to solve in such cases.
Where «trivial» and «doable» mean «non-obvious» and «can easily break downstream modifications for no good reason»
Rolling back is a serviceable / kludgey workaround that's ok for now but symmetries in F360 are fundamentally broken and need a major overhaul.
Just because it's not completely unusable doesn't mean nothing should be done with them and this is the idea station not the kludgy work-around station 🙂
Well I just want to echo everything Roambotics_Scott is saying. For me as a new user I was supprised that regular copied compononets work and not the mirrored, I mean they work in other programs so I was sure I did something wrong. Until I relized it just simply doesnt work. And I dont know the code behind the program so I can't say if it is easy or not, but mirroring something in general is real easy math.
And for now I will probably use the timeline for this, but it just feels wonky because I want to see my mirrored update as I performe them to judge if it looks nice and harmonic togeather, I dont want to jump back and forward for every change I do to see if it works togeather. Or as Scott says it's "kludgy" 🙂
It's small things like this getting fixed that will make the app shine even brighter.
As I said, I don't have a problem inproving the functionlity.
I have a problem with the statements made in the original idea because they are false!
Your statement was that the original "link"is broken, which is not true. You might not like the way to maintain the symmetry by the workflow I suggested but it does work invalidating your statement. If you re-write the idea I might vote for it.
What ideas that are written with such statements do is they send a signal to other users and manifest the believe that there is some functionality missing. If you would have created a screencast showing the functionality - or wonky, kludgey wrkaround - with pulling back the timeline and elaborated why it is lacking and how you'd like to improve that functionality I'd been fine with it.
Alas, you did not. In that context whether or not the workaround is klunkey is entirely irrelevant.
Yeah I'm sorry @TrippyLighting but @Anonymous is right. Symmetries are badly broken in general and way beyond anything to do with bodies vs components and the timeline and I say that with I think at least as much experience with it as you.
I've shared this before but here is an example of partially broken symmetries handled exceptionally well
Really don't know how you can look at that or even just basic patterning and mirror / rotational symmetry systems in other applications and think that what F360 does is remotely acceptable.
Not only that but if new people are coming in confused about bodies vs components and why you have to rewind the timeline not to break symmetries (which still makes no sense to me), they're telling us that the interface is confusing and non-obvious. Much better to listen to people with fresh eyes than simply to say «I don't see the problem / get used to it»
It's fantastic in many ways but pretending basic essentials aren't broken (or just not seeing them) is only going to keep it from getting much better.
May be the term "broken" is what strikes me as wrong. English is only my second language and very occasionally I overlook a nuance.
To me broken means "I cannot do my work" or "It cannot be done". Based on the feedback here on the forum I see that a lot of users also see it exactly that way. But it is not true. You can do your work as I've shown.
OK. I remember you posting that video before. That is without a doubt a beautiful and well thought out implementation! This explains much better how this ultimately should work and you've convinced me to vote for this idea!
Yeah «Broken» here doesn't mean «can't do your work at all», but that you have to go through unnecessary contortions to do things that should be easy.
In this case, it's more along the lines of «imperfect» in the sense that a car that only lets you turn right is imperfect - you can still get around, but it'd be so much better if you could also turn left.. guess that's a matter of degree, but imo it still seems fair to call a car with that issue «broken» in the «gebrochen» sense 🙂
Well I actually had a post on Mirrored Components in DM or something like that and from my convo with AD Staff, it seems with the way Fusion is currently programmed, it'll take a while before a more elegant solution can be implemented.
I guess, not having a proper Part vs Assembly file types is causing this whole mess when it comes to recording timeline as traditionally, your feature actions is recorded in part level and not in assembly but in Fusion, since there's no distinction between part vs assembly, all of your actions (move components and etc.) is recorded which in the long run, ends up giving user with an unwieldy long timeline.
Im not saying that having Components only is a bad idea as there's some real neat modelling techniques that comes out of it, but it does introduce a new set of problems that sadly doesn't have a good workaround...yet.
Thank you for your idea, this is getting archived due to the design intention of this feature and the discussion in this thread. When you mirror a component, the mirror happens at a specific point in time. Mirror component is not a instance of the original component and does not function as symmetry. There are several ways that you can create a model that will up date in this way:
1. Use mirror component and when you would like to add a feature to both sides roll back the timeline and edit before the mirror.
2. Copy and paste a component. This workflow will create an instance of the component and annoying thing that happens to one will happen to the other.
3. Create a component and save it to the data panel. Then start a new model and insert the component multiple times.
Seriously couldn't disagree with you more on this, @promm
If that's by design, you guys should really reconsider the design. It would be hard to come up with something less intuitive or more likely to cause problems without doing it on purpose.
If you're going for design intent, watch the video I've shared a few times to see an example of that done well. You don't need to copy that but whatever you do should at least be as natural and obvious if not more so.
Just reread what you said @promm and I just think you're completely missing the point of design intent and internal symmetries.
Nothing you suggested would support reflection symmetries. If I want to design something where one side is a mirror image of something else but I need to work with the complete body then using the temporal voodoo I'd be stuck because as soon as the symmetry exists, it's broken.
You're asking users who want to do that or design a single component that mates to itself to either know in advance exactly what they want (in which case, why not just do it on paper or with classical Autocad ?), or they have to keep jumping between the past and present but add things in the past that are circularly dependent on the present which F360 doesn't support, so they'd have to hand measure and copy lengths, radii, and angles from the present, jump to the past, put those in by hand, and really, really hope they don't make any errors.
The whole point of having symmetries is that as you make changes they're propagated everywhere unless you explicitly break them.
