Question about using mesh-objects (imported STL and others)

[Anonymous]

There a few things about "mesh-objects" which I don´t quite understand and would need some clarifcation on.

When I import some files like STL, these are generally available as mesh-bodies. I understand that these objects are different to T-spline bodies or other "constructed" bodies in Fusion360, and that some limitations in editing arise from this. However, what I do not understand are some of the limitations concerning using the mesh objects as a whole.

Some of these things might just be limitations (missing features) of the software, while others might be inheritly impossible. Therefore, before suggesting anything in the IdeaStation I wanted to ask here first.

Why can´t I ( or how can I 😞

- use simple joints to attach multiple such mesh objects as components? 

- create custom-joints based on mesh-vertices or mesh-faces?

- define new geometry (i.e. constructions planes) based on faces of the mesh? Each mesh-face would still define a clear plane, right?

- perform a simple Boolean "trim/cut" with mesh-bodies?

Also, I´ve recently opened a (downloaded) STL file which gave me one component with multiple mesh-bodies. I don´t seem to be able to create different components from these bodies (i.e. have each of the bodies be a one-body-component). Why?

[jeff_strater · Accepted solution]

Hi @Anonymous,

These are all good questions.  Thanks for posting them.  Your insight is pretty accurate.  It is a mix of "we just haven't gotten around to them yet" and "these things are harder than they might seem".

I'd lump some of these:

- use simple joints to attach multiple such mesh objects as components? 

- create custom-joints based on mesh-vertices or mesh-faces?

- define new geometry (i.e. constructions planes) based on faces of the mesh? Each mesh-face would still define a clear plane, right?

into one category:  We don't yet have a system where we can reliably "track" a mesh vertex or facet.  So, in a parametric design, if you do something like create a joint to a mesh facet, we have to be sure that when you edit the mesh, the joint finds the correct facet again.  This is the "it's harder than it seems" category.  The same goes for things like creating a workplane on a mesh, sketching on a mesh, projecting mesh vertices and edges into a mesh, etc.  None of this is impossible, but it is hard, and we don't have a great solution for it yet, to be absolutely honest.

The rest are probably just stuff that we haven't gotten to, or isn't seen as high priority for enough customers yet, to implement.  For example, enhancing the Create Components From Bodies command to account for mesh bodies.  So, adding IdeaStation requests for mesh stuff, and getting others to vote for it, is effective over time.

Personally, I'd like to see us emphasize mesh a bit more.  A lot of content these days seems to be in mesh form, and if Fusion were better at dealing with meshes, we would be able to solve workflows that are somewhat unique.  Votes from customers for these ideas can go a long way towards making that happen.

Jeff

[Anonymous]

Hi @jeff_strater,

thanks for the confirmation. I can see the problem of "following" up on faces in meshes.

However, I assume that some "origin" point in the mesh-object exists, right? Wouldn't it then be the "logical" thing to do just to define any (used) face/plane as normal vector of that face and - whenever the mesh actually is edited - "break" the link (just keep the static information) in the same way other things in the "history" can break and become yellow alerts?

It might be less "ideal" than having things really being "smart", but it would get you a loooong way in the direction of making good use of mesh-objects. In particular, when one only wants to "use" imported mesh-objects as assemblies etc.

One could make a quite simple "check":  Number of mesh-vertices/faces changed -> Break stuff. (?)

Of course, it's always simpler to suggest such things if one doesn't actually need to look into the code and do it  (I'm working as software developer) ;c)

But in this case it seem to be that "a simple half-solution" is better than "no" solution.