Allow snapping to imaginary cone vertices

[kb9ydn]

See these threads for some background:

https://forums.autodesk.com/t5/design-validate-document/fitting-flat-head-screws-to-countersinks/td-...

https://forums.autodesk.com/t5/design-validate-document/how-do-i-join-two-chamfered-surfaces-to-each...

What is needed is a way to use the theoretical vertex of cone shaped objects as a point of reference for modelling and joint alignment.  A simple use for this would be in joining flat head screws with countersunk holes, such that the screw head stays in contact with the countersink if the hole size or countersink diameter/depth are changed.  There are ways to do this now but none of them are very efficient.  There are potentially many other uses for this as well.

C|

[SEIZMICdesign]

Or just a "hole wizard" a la SolidWorks.

[kb9ydn]

The Solidworks hole wizard is awesome, although that's not really what this is about.  Fusion has a hole wizard already; and while it is somewhat primitive (for now) it does its job ok.  The problem here is when you try to join a flat head screw to a countersunk hole as created by the hole wizard, the only way to get it to seat correctly is to adjust the offset of the joint.  There are workarounds for this but they aren't very efficient.

This idea request goes beyond the hole wizard and applies to any conical geometry at all.

C|

[_ritchie]

Just a note that it'd be more ideal to have Fusion figure out the cone vertices of two conical surfaces and do the snapping as part of a 'conical mate' type rather than needing to expose a 'virtual vertex' to the user - that's a leaky abstraction that shouldn't be necessary.

When possible we should be requesting functionality that meets our requirements (use case: mate flat head screw to countersunk hole), rather than defining specific implementations for people. Doing the latter just means they need to do the extra work of reverse engineering a requirement from a spec.

Best,

Ritchie

[kb9ydn]

@_ritchie

I agree.  Idea requests should be limited to describing needed functionality and not get into implementation details.

In this particular case, if the intent was only to have a method for joining conical objects, then we wouldn't really care about cone vertices.  But having an available snap point at a cone vertex could be useful for other modeling functions beyond joining components.  So the requested functionality really is to "allow for snapping to a cone vertex".  Using it for joints is just one example.

C|

[_ritchie]

@kb9ydn Agreed that snap points at cone vertices could indeed be useful for other modeling functions, just wanted to make sure the idea presented here reflected the request - so far the linked threads and examples don't really motivate those potential other modeling functions and they still remain a little vague.

If there's a situation where having cone vertices extracted is central to the use case (e.g., aligning cones of different angles) then for sure let's elaborate it.

Best,

Ritchie