What's the best way to edit custom features after creation (eg Spur Gear)?
I'm about to try this by jumping through a bunch of hoops involving the marking menu and attributes on the objects. But I can't tell if all the pieces will fit together yet. I saw mention of 'client features' in one of the blog posts a while back (http://modthemachine.typepad.com/my_weblog/2015/09
Funny that you should mention the spur gear as an example because I have plans to add this behavior to that add-in. I did some work in the last update of that add-in to enable edit functionality later when the context menu functionality would be available. The context menu is available now but I haven't had time to update the add-in yet but I can tell you what I was thinking about how I'll go about supporting edit.
The thing that I did before and is already in the current Spur Gear add-in is that I'm adding attributes to the gear component that the add-in is creating. These attributes contain all of the information that was used when the gear was created; essentially all of the settings in the dialog. I can use this later when editing the gear to initialize the dialog with the current gear values. Also, just the existence of this attribute on the component tells me that it's a component created by the spur gear add-in.
My plan was to add handling of the markingMenuDisplaying event to the add-in and watch for whenever the entity currently selected is an occurrence that references a component with the attributes I've added. Whenever that's true, I'll add a new "Edit Spur Gear" command to the context menu. If they select the command then I'll display the spur gear dialog but initialize it with the values I get from the attributes. They can now edit any of the values and click ok.
Now, there are a few decisions to make about how to change the gear. I haven't decided which way to go with the spur gear yet. The easiest thing to do in my case will be to delete all of the contents (sketches and features) of the gear component and re-create the gear geometry. The problem with this approach is that anything that referenced any of the gear geometry, (for example, creating any joints on the gear), will go sick because the geometry they referenced no longer exists. The other approach is to try and modify the existing geometry. This would be quite a bit harder but better for the references.
Depending on the geometry you build and the changes that can be made, it might be possible to just change parameter values to get the new shape. If you can construct the model in a way that this works, that would be the easiest of all but it's not an option in the case of the gear because the shape of the tooth isn't define parametrically.
Your approach is what I was thinking might work in a pinch. A bit of a hack though no? Shouldn't the parameters of a feature be model parameters instead of attributes? (I understand that the add method is not exposed in the api and that's why you are using attributes. But the point is that features should be consistent whether created by the user or not.)
I poked around the api a bit more, and I have a better feeling for where the developers drew the interface boundary now. It appears they had a meeting and said something like:
"Only we, the grand wizards of topology, geometry and UX, are capable of the intricacies of feature creation. Any user wanting to get stuff done shall wait for our permission and the blessing of our wisdom. So shall it be."
Hopefully there is a bold and clever visionary in their midst, who no doubt at great personal risk, will, like Prometheus, bring the Client Feature to the masses.
Until then we wait in the darkness...
Thanks for your reply. In the case of the spur gear generator you might reconsider how you have it set up. You should probably be building the gear teeth off existing hub geometry. I think gear teeth are usually a final detail (you are not often modifying the faces of the teeth with additional features). In which case deleting and rebuilding the feature works fine. Dependant geometry will reference the hub and be unaffected by changes to the teeth.
As a side note, I'd choose to use an existing cylinder face to define the pitch circle as my first 'parameter' and then add details from there, as that better matches the design workflow for both custom and off the shelf gears better. (One chooses a ratio and sees if the volume is acceptable before choosing things like tooth size or backlash).
Some of what I suggested is a bit of a hack but I think it's the only solution given the current tools we available.
We've had discussions about providing the ability to create custom features and it is something we plan to do, so it's not something that we've intentionally hid. With any new feature we have to weigh the benefits vs. the cost. Custom features definitely provide some benefit but at a very high cost. The cost will also be across several teams so the impact on resources is high. When weighed against other things we want to do that have a high benefit and much lower cost the prioritization of custom features puts it lower in the list.
Regarding your comment about using parameters instead of attributes; I don't see that as a use this or that question but instead see a use for both. Unfortunately, until custom features are available there isn't a good way to take the best advantage of parameters. But even if I could there would be some things that make sense to expose as a parameter and other things would be a "property" of the feature which I can store as an attribute. For example, when you create an extrusion there are parameters for the depth and taper angle, but there are a lot of other settings (extent type, operation type, etc.) that are stored by the feature.
And finally, regarding your comment about how the spur gear program works; I agree that it might be better to allow the selection of an existing cylinder and add the gear to it. The API samples weren't necessarily designed to be full featured utilities but are samples demonstrating various capabilities of the API. The fact that they are sometimes actually useful is an added bonus.
Ah, you are one of the wizards ;)
I understand prioritization of capabilities. Also that few users are likely to exercise the api. And that certain approaches to implementing features internally could make exposing a generic interface difficult. All good.
I see what you are saying about storing object properties in the attributes collection...
Seeing as how this is a recent post and I was in here searching on this very subject. I would like to tag on to this discussion.
I was thinking about expanding the gear creation capabilities in exactly the way you have described. But my ambitions go further. I created a set of tools for OpenSCAD to create gears. I started with the thinking that gears are always created in pairs and extended that concept to gear trains. So when creating a gear one could also create a compatible gear. And since a subsequent gear in a gear train would be along a shared shaft I added the ability to give a direction and length offset to the next gear in a train of gears. Ultimately, I had a mechanism to define an gear train in a specification. I also had a function that scanned the gear train specification and validated the gear pairs (or more in the case of planetary gears etc.) and output where there were problems and why.
I also had helper functions that allowed one to use different approaches to defining a gear. These helper functions originally were to aid in using the various different ways in which manufacturers specific their gears. They expanded to cover other things like creating a pair of spur gears given the distance between two shafts and the desired ratio etc.
The concept is that I have developed a knowledge about gears (more than one would expect an EE to have) that I would like for others to leverage. The example of designing spur gears to go between two shafts is but one of many use cases where a tool could solve the problem so that one does not need to understand in great detail how gears work.
And I would like these tools to act like all the other tools for parametric design. That one could go back and tweak the parameters and have the effects of the new parameters propagate through design.
My tools covered bevel gears, spiral gears, etc. And helper functions are even more useful for these types of gears. In fact, my dream is to understand and implement the tooth shapes for hypoid gears.
And Brian, I am thinking one can parameterize gear tooth profiles. There are several papers on describing the involute curve using beziers, b-splines or one of the other polynomial curves. These curves take fewer points and are actually more accurate than the piece-wise linear approach most often used. And they can be defined parametrically and not as a series of programmatically generated points of the piece-wise linear approach.
I am just learning the API and have no where near the experience that I had with OpenSCAD. Presently, I am not seeing clearly how one might create tools in the style of being part of a parametric design. All the examples I see of scripts are more like macros than things that become a part of the whole parametric design. Am I too ambitious? If not, do you have advice in where I might look for better examples? One of the great things about OpenSCAD was that there was (is) a large number of examples that I could look at and learn from. I haven't found that mother lode yet for the Fusion 360 API.
Since I wrote the last post, I have done some investigating to see what has been suggested in the Ideastation. I found this video from your design team from over three years ago.
It kind of takes away any motivation to work on this if a better solution is already in the works. But, three years is a long time in today's world. What is happening with this tool? Is it dead? Can I justify spending my time working on a gear design tool?
I think the proposal from three years ago would get a lot more votes but it is confusingly placed in the Ideastation. It seems to be tied up with a bolt connection tool and it appears that the bolt connection tool is the proposal one is voting on..
Additionally, there are multiple requests for gearing tools in the Ideastation. With separate proposals getting votes it dilutes the individual proposals and makes a gear tool seem to have less demand than it actually does.
Personally, I use gears a lot. They are very handy for 3D printing of various gadgets.
I have also seen that at least one of the gear design tool requests has been marked as implemented. I think the manager who did that was using your spur gear script as justification for closing the request. You and I both know that he is mistaken. Is there a mechanism to appeal his decision? A higher level authority or some kind of review board perhaps?
I have worked for giant corporations (AT&T for one) and small ones as well. In the giant corporations, management's lack of technical expertise and inability to defer to the ones with the expertise was frustrating. I can see that Autodesk has the same malady. I understand that they have limited resources, but using techniques like this to ignore the demand for a tool is silly at best. It is insulting to your customers.
PS I see you as one of the people with the technical expertise that probably gets ignored by management. We are clearly in this together. At least you are allowed to interact with customers. Autodesk has done that right!
Thanks for your vote of confidence and I certainly understand your frustration. I hadn't seen that video and don't know what's going on in that area. I'm fairly certain that the work has been shelved while work is done on other projects deemed to be a higher priority. Inventor supports something called "Design Accelerator" that is quite a few tools to automate the creation of geometry that fairly common in typical design, like bolted connections, spur gears, shafts, bearings, cams, etc. The video is a port of some of the spur gear functionality. It would be nice to have in Fusion. The "Design Accelerator" functionality was written using Inventor's API but it would be difficult to port straight over to Fusion because of some basic differences between the two programs. In some cases there is missing functionality in Fusion that it needs and in other cases there are just differences between the two programs that would take some effort to overcome.
The best thing to bring attention to this would be to create a new item in the IdeaStation and be fairly specific about the capabilities needed and pointing out the deficiencies of the current solution. If there are a lot of other customers interested in the capability it will get noticed. If there isn't much interest by the community, resources will likely be used on other items that more people are requesting and interested in.