Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
Comments
oh its public now
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
You got a query variable set to evaluate on use with all solid bodies. The bodies being inserted are pretty solid after insertion. That means they get added to the subtraction scope. Was scratching my head real hard for that one.
Derek Van Allen | Engineering Consultant | MeddlerV16 - New updates: global rotation of all seeds to make flipping stuff easier. Composite part support for insertion operations.
Derek Van Allen | Engineering Consultant | MeddlerOmg that's it! insane. It was an excellent case study in why it's important to capture ALL of the right logic with your Query Variables, not just what happens to get the selection you want right now. I was actually able to fix it by declaring another qv of the same name with "evaluate on use" UNchecked. That's an interesting workflow I'd not considered. You can essential turn "evaluate on use" off/on at various points in your tree that way.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
@EvanReese there's probably some utility there as well by starting with a QV evaluated one way on startup and then running a new QV with the same name copied into itself stored as Selection as some kind of cache, or to recursively iterate on queries. Or a qNothing.
Derek Van Allen | Engineering Consultant | MeddlerHi @Derek_Van_Allen_BD. The new update that has the spin feature is nice! It seems like I have lost the ability to rename the feature to anything other than "Amalgamate" though. Not sure if it's a problem just on my end.
@jason_ryan337 yeah that's a breaking change that I made so that the naming happens in the tagging step. An unfortunate but necessary sacrifice to allow computed properties into the naming field to allow you to control the amalgamates at the source. The only way to get both the ability to rename the feature and allow computed property naming simultaneously is if I re-declare the feature itself as either hole or routingcurve explicitly because those are baked into the Onshape UI at the global level. It would require a change by the developers at Onshape to allow this for other custom features that don't have one of those two feature declarations. @ilya_baran
Deleting and reapplying the tag and amalgamate features will allow you to take advantage of the new ability to store names in the tags and drive them with variables based on the part configuration.
Derek Van Allen | Engineering Consultant | MeddlerGotcha. So the naming convention can change dynamically from the source side. Like the length/width of features can be pulled into the name? I tried using a # in the optional name, but it didn't seem to allow a variable though.
I am not sure about others, but I have a lot of instances were I have more need for discernment on the destination side than the source side. Often I might need to apply a feature differently to the right side of a part than a left side. I'm not sure if there is a good way for me to discriminate.
Two ways to go about it, you can either set that field to evaluate as an expression, which I did in my screw thread sample to check that it even works, or you can drive the field with configuration settings which works well enough for parts where you've only got a few dropdown options and you don't feel like wrapping your head around expressions logic.
I should make an expressions builder feature to make that side of things easier.
Derek Van Allen | Engineering Consultant | MeddlerThanks. I didn't think to re-open the example file. I'll look there for a reference! Appreciate it!
Well in your defense I'm not doing a great job linking back to the examples and writing clear documentation at the moment cause I'm rushing out some sheet metal magic elsewhere. It's the screw test block tab if you find your way in there.
Derek Van Allen | Engineering Consultant | MeddlerSmall demo of some capabilities of the feature:
Derek Van Allen | Engineering Consultant | MeddlerThis is awesome! Pulling this together into one feature is very neat! Also love the tag approach.
Interestingly, we have been using this exact modelling practice extensively and use @NeilCooke and @ilya_baran's Super Derive feature for that (https://cad.onshape.com/documents/cfef86ed4f9635531599a973/v/f4bb83e64d800c3dfe88e02e/e/1ca336dd47d98dd00918c589).
I even did a presentation on it at the Onshape Research Symposium 2023, recording here: https://www.youtube.com/watch?v=fGOWO5yoiao
We happen to call it 'boolean modelling architecture', and call basic geometries 'atoms' and geometries composing of atoms 'molecules' as we create multi-use geometries, it's nice to keep them apart semantically.
One trick that should be mentioned is that versioned or released geometry is of preference. Apparently, that is cached in Onshape and don't actively regenerate to upstream or downstream changes, potentially causing significant regeneration time, even more severe in multi-layer amalgam structure. Therefore, Amalgam geometry should either live in a different document, or be careful to always point to document versions within the Amalgamate insert feature.
I figured I wouldn't be the first to approach modeling this way, Point Derive and Super Derive have been around long before I got introduced to Onshape. For the longest time we were using Point Derive as our source control engine and I was starting to write up an internal document I prospectively titled "Point Derive Is All You Need" that walked through the Boolean Modeling Architecture that you describe in your video. In practice though what I found my team needed was really Three-Point-Derives-in-a-Trenchcoat because they kept doing additive and subtractive geometry in the same seed locations with different targets so that first led me to develop Poly-Mate Connectors to be able to easily re-select the same anchors for the multiple operations. Then Sheet Metal Form came out and gave me the clear roadmap for implementing Amalgamate.
Had I seen your video prior I might have chosen some clearer semantic language or borrowed your terminology for the feature. But there's also a problem with discoverability for custom features right now even if you use the publishing system that I've chosen to combat with putting the most useful features I develop behind funny names. Partly banking on people spreading the features around like memes, partly hoping that the silliest ones might rage bait the developers into getting the features integrated first party to the software, or that they develop that first party feature store so I can use a tagging and filtering system like a normal human being instead of relying on Minecraft mod author energy.
Derek Van Allen | Engineering Consultant | Meddler@wille_j Thanks for sharing the video. I know we've talked about the methodology in the past, but it was good to have it all right there with images to support. I've used super derive for similar things for years, like making the holes needed for a bearing and retaining ring, but the more I think about the method the more sense it makes to me. I think Amalgamate takes it one step farther, which is terrific! BTW, I'm working up a version of Hole that makes positive bodies for use with atoms/molecules, since the hole attributes and cosmetic threads will transfer through a boolean operation. Should have it available soon.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
Waiting on the edge of my seat for Anti-Hole to debut. Just today someone on my team came up with another, different attempt at it that is even more limited than the first couple. The people are hungry for inverse fastening features.
Derek Van Allen | Engineering Consultant | MeddlerOkay it's ready! Plus more video about amalgamate.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
Looks to be a few bugs with tap holes generating as new bodies and not having a target body in front of them. Looks more stable than the last several attempts we did internally though so I'll do some investigation with this version.
Derek Van Allen | Engineering Consultant | MeddlerOh it's a vibe code monstrosity, honestly. I wanted to try a different approach to using GPT as a learner, but I've learned that I really don't love coding that way. It removes all of the discovery, learning, and skill building, and replaces it with an afternoon of arguing with a robot only to result in bloated code that I don't fully understand. My next Codex shouting match would be to address the editing logic, which makes sense for a feature that only cuts things, but not for this one. I think it's essentially just adding a different logic fork for NEW and ADD and keeping it all for REMOVE.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
I've definitely been through that experience with default GPT and my method to get past it was to load the full standard library into a forked repository and write a huge list of custom instructions to tailor the engine to avoid common pitfalls. There are definitely deficits to the vibe coding approach in regards to discovery and learning but the raw potential for output keeps it as my primary tool.
Derek Van Allen | Engineering Consultant | Meddler@EvanReese If you want to discuss LLM coding approaches, happy to get on a call with you.
Simon Gatrall | Product Development, Engineering, Design, Onshape | Ex- IDEO, PCH, Unagi, Carbon | LinkedIn
Absolutely @Derek_Van_Allen_BD, I love the way Amalgamate takes all the positive and negative volumes into one feature. It's a much more streamlined process. And the tag feature is such a neat way to handle that annotation at the source. I've used tag functionality before in enterprise features I've made for completely other things. It separates out the intent of what's 'inserted' in a neat way.
I'm in no way criticizing the choice of name for the feature, there's usually many different ways to say the same thing. I rather found it amazing to see more users of the same principle of design and wanted to share our experiences with it. As you say in the original post, there's often no need for custom features, just clever tool studios, derive and boolean, now made even more streamlined! Wrt to the name I actually find it excellently chosen, I'm not a native English speaker, so the name didn't instantly click for me but after a quick google dictionary search I got it.
I definitely agree that custom feature find-ability is struggling, it would be nice to see some more care in that area. It's such a powerful and ultimately central part of Onshape that it's a shame it don't get more of it's own space. I have actually not thought of it earlier or tried, but it could be possible for the AI advisor to really shine if it would be able to recommend custom features for tasks!
- "I want to derive and then boolean subtract a part, how do I do that?"
- "That's a great workflow! I would recommend you use the Amalgamate custom feature that does it all in one go <link>."
Glad it's of use @EvanReese :)
It definitely takes a little while to get used to modelling 'in reverse' i.e. what will be the empty space. And I agree Amalgamate wraps up the methodology into an incredible package.
Yeah, I actually saw the Youtube comment you got about the inverse thread and knew you were instantly on it! I have not yet had a personal deep-dive into the FeatureScript aspects of MBD, only the two intro videos from @GregBrown which were great. I definitely hope 'inverse' MBD annotations would follow with instantiate, and it might be another good area to expand Amalgamate and/or other features just like the inverse hole attributes.
Go throw your vote and comment on the Feature Store improvement request thread if you haven't already. I plugged the suggestion into a recent video that I did that I knew would get visibility from the developers but it's definitely harder than it needs to be to find and sort custom features. Even with the publishing system.
Derek Van Allen | Engineering Consultant | MeddlerAny chance you could open up those hole table definitions to allow for configuration? I have a use case for that ability even though data needs configured in 2 places
Derek Van Allen | Engineering Consultant | MeddlerDone.
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
@Derek_Van_Allen_BD two small asks for Amalgamate:
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com
@EvanReese can do #1 for sure. #2 I'd want to think about a little harder because I would personally consider that objective as 2 separate configurations of the original tag studio. I could easily make the scopes optional but I'd want to think of all the downstream implications where maybe someone turns off one of the scopes accidentally in the feature and you end up not getting clearances the way the standard should define.
Derek Van Allen | Engineering Consultant | Meddler@EvanReese delivered on #1
Derek Van Allen | Engineering Consultant | Meddler