DVE2000
IDEA: update dogbones
Hi Peter,
please see this issue as an idea. Parametric design is awesome, unfortunately fusion sucks, whenever it comes to base features, as they do not update, when the model changes. Autodesk wanted to provide an api for custom features, where the feature can define it's dependencies and once a dependency has changed the api allows a re-calcation of the feature.
The status is since years unchanged and the feature is totally unstable. I've tried examples from the forum and none of them worked. Since a while, I'm playing with the following idea that could hack around this limitation.
- create a new command to update dogbones
- on execution, go from start to end through the timeline and identify all dogbone features. To my knowledge a feature can have a name, so a simple prefix could help here.
- find the relevant parameters and create a new feature in the timeline, delete the existing one. The parameters, like, faces/bodies or selected edges needs to be persisted. As fusion doesn't provide a way to do so, I could see that the plugin, would create it's own data store on the hdd. e.g. ~/.dogbone/<design_id>/<feature_id>.json
Limitations:
- extra storage needed, that is not persisted inside the file, e.g. f3d.
Hi Tony,
Brian Ekins has done that for his nifty dogbones, I've played with the idea but got sidetracked when custom features reared its head. The idea of the custom feature is awesome and perfectly positioned to do exactly what dogbones needs, but you are right any update to the bodies doesn't trigger an event as it should. Without that, custom features is ham strung. Knowing my luck, as soon as I've spent a good amount of time developing a work around, AD will come up with a working solution to their custom feature.
The limitations you mentioned isn't actually that big a deal. Almost every entity in F360 has a parameter capability which allows data, even json, to be saved with the model. It's possible to provide a group name to the parameters, which makes retrieving specific parameter types almost trivial.
The biggest hurdle I've encountered is having to effectively reconstruct all the objects in the add-in each time, not only when F360 starts up the dogboned model, but also when you edit the feature in the timeline. The latter isn't awful, as it's possible to persist the add-in. However, managing which dogbones were created when, and pulling up the right parameters requires a good underlying strategy - all of which was inherently offered by custom features.
If you've had a chance to look through my messy code, you'll see that I've tried to make it as OOP as possible. I keep lists of active faces, edges and occurrences in objects - all of which are keyed by the respective entity tokens - it's relatively easy to find a face object from a specific bRepFace, and vice versa. Finding a way to reconstruct those lists needs a bit of thought - I don't think it's trivial unfortunately.
The face and edge objects should be structured usefully enough to allow the reconstruction mechanism to be added without major disruption to the rest of the code. If you have any thoughts, I'd be happy to look at working towards the next version.
One of the things on my todo list is to add a few more comments to explain some of the rationale behind the code. I was hoping it would be readable as it is, but going through it again, I realize I'm missing some key explanations.
Peter
Get Outlook for iOShttps://aka.ms/o0ukef
From: Tony Findeisen @.> Sent: Wednesday, September 20, 2023 4:19:36 PM To: DVE2000/Dogbone @.> Cc: Subscribed @.***> Subject: [DVE2000/Dogbone] IDEA: update dogbones (Issue #61)
Hi Peter,
please see this issue as an idea. Parametric design is awesome, unfortunately fusion sucks, whenever it comes to base features, as they do not update, when the model changes. Autodesk wanted to provide an api for custom features, where the feature can define it's dependencies and once a dependency has changed the api allows a re-calcation of the feature.
The status is since years unchanged and the feature is totally unstable. I've tried examples from the forum and none of them worked. Since a while, I'm playing with the following idea that could hack around this limitation.
- create a new command to update dogbones
- on execution, go from start to end through the timelinehttps://help.autodesk.com/view/fusion360/ENU/?guid=GUID-c032ce7b-96f7-4af6-8679-e0862063f987 and identify all dogbone features. To my knowledge a feature can have a name, so a simple prefix could help here.
- find the relevant parameters and create a new feature in the timeline, delete the existing one. The parameters, like, faces/bodies or selected edges needs to be persisted. As fusion doesn't provide a way to do so, I could see that the plugin, would create it's own data store on the hdd. e.g. ~/.dogbone/<design_id>/<feature_id>.json
Limitations:
- extra storage needed, that is not persisted inside the file, e.g. f3d.
— Reply to this email directly, view it on GitHubhttps://github.com/DVE2000/Dogbone/issues/61, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABBJGTBMG4J3MG4J6OC6XDTX3NFVRANCNFSM6AAAAAA5APHRVM. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hi Peter,
Knowing my luck, as soon as I've spent a good amount of time developing a work around, AD will come up with a working solution to their custom feature.
That wouldn't been the worst case. I think it's time to start, so that either the work around is available or AD fixes custom features.
Almost every entity in F360 has a parameter capability which allows data, even json, to be saved with the model.
Awesome!
The biggest hurdle I've encountered is having to effectively reconstruct all the objects in the add-in each time, not only when F360 starts up the dogboned model, but also when you edit the feature in the timeline
I think edit feature is not available, if not using custom features at all.
TBH, if I see my workflow, I'm designing something that I can produce in a flat bed way. Last steps are always adding finger joints and afterwards adding dogbones. Every chance, even in material size (use parameter) leads to the fact that I need to remove all finger joints and dogbones and recreate them. Almost never I see a need to change the selected face or restrict the edges.
Having that said my feeling is that even only remembering the body/face and the parameters used would be enough. At least for my workflow. A simple update dogbones command and I'm good to go after a material thickness change or change of the size of the model.
That's also why the parametric creation was important to me as with the sketches it creates the same goal can be achieved. It updates automatically on changes.
I understand the problem that only remembering faces and parameters is not the 100% solution, but a 90% at least.
If you've had a chance to look through my messy code, you'll see that I've tried to make it as OOP as possible
I've checked this and I have the feeling that separation of concerns need to be smaller. Then it's also more testable. Having tests and linting checked on CI would be a goal. Also external dependencies shouldn't be part of the source code, there should be a way of installing them and bundling them together during release time.
I'll take a look on those topics, if you agree.
Tony
Hi Tony,
I've just been thinking about your suggestion overnight, and I'm not sure it'll be too difficult to implement. I've been hung up waiting for custom features, but you've prompted me to look at this approach again. Watch this space.
I've also discovered that the logger mechanism I've embedded doesn't work as I expected. I guess I made some changes when I went to full face and edge objects/classes and I didn't check carefully enough. Almost no one has used it but me, so generally not a big deal - it just makes more work for me now.
Peter
From: Tony Findeisen @.> Sent: September 21, 2023 3:34 AM To: DVE2000/Dogbone @.> Cc: Peter Ludikar @.>; Comment @.> Subject: Re: [DVE2000/Dogbone] IDEA: update dogbones (Issue #61)
Hi Peter,
Knowing my luck, as soon as I've spent a good amount of time developing a work around, AD will come up with a working solution to their custom feature.
That wouldn't been the worst case. I think it's time to start, so that either the work around is available or AD fixes custom features.
Almost every entity in F360 has a parameter capability which allows data, even json, to be saved with the model.
Awesome!
The biggest hurdle I've encountered is having to effectively reconstruct all the objects in the add-in each time, not only when F360 starts up the dogboned model, but also when you edit the feature in the timeline
I think edit feature is not available, if not using custom features at all.
TBH, if I see my workflow, I'm designing something that I can produce in a flat bed way. Last steps are always adding finger joints and afterwards adding dogbones. Every chance, even in material size (use parameter) leads to the fact that I need to remove all finger joints and dogbones and recreate them. Almost never I see a need to change the selected face or restrict the edges.
Having that said my feeling is that even only remembering the body/face and the parameters used would be enough. At least for my workflow. A simple update dogbones command and I'm good to go after a material thickness change or change of the size of the model.
That's also why the parametric creation was important to me as with the sketches it creates the same goal can be achieved. It updates automatically on changes.
I understand the problem that only remembering faces and parameters is not the 100% solution, but a 90% at least.
If you've had a chance to look through my messy code, you'll see that I've tried to make it as OOP as possible
I've checked this and I have the feeling that separation of concerns need to be smaller. Then it's also more testable. Having tests and linting checked on CI would be a goal. Also external dependencies shouldn't be part of the source code, there should be a way of installing them and bundling them together during release time.
I'll take a look on those topics, if you agree.
Tony
— Reply to this email directly, view it on GitHubhttps://github.com/DVE2000/Dogbone/issues/61#issuecomment-1729015997, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABBJGTEAR2ULH36PM7K46C3X3PUWZANCNFSM6AAAAAA5APHRVM. You are receiving this because you commented.Message ID: @.***>
Hey Tony,
I've got a working version of update here. It should update to any type of dogbone.
I've fixed several significant bugs as well as adding better comments, and hopefully simplifying some of the code.
I've taken the liberty of using the update icon you created. I will credit you, not only for the icon, but also for the amazing work you did on refactoring and making the addin look significantly more professional. Thank you.
I hope that this is something you can use, even if it's pulling in functions into your Doge addin.
Peter
Hey Tony, I've updated the addin to v. 2.2. I've added update button, fixed several bugs, and the dogbones should now work not only in the Design workspace, but also in the Manufacturing Model environment too. I have used ALL your PR changes, and I think I've learnt from my merge mistake. I'm so sorry that happened - I was struggling for over a week to correct my error.
The update feature accounts for all different types of dogbones without doing a blanket change to a default db type. I'm now starting to look at ways of editing the selected dogbones - to allow different types to be selected or changed.
Regards Peter
Hi Peter,
sorry for being silent for such a long time. I've been busy with other stuff and needed to take care of myself for the last days. Great to hear that you've made such a huge process. I'll check it out, whenever I'm full recovered.
Best regards, Tony