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.
Who cares about meshes.
I am wanting to create a feature script that converts a polygon mesh to a quad mesh.
The Onshape API doesnt communicate low level poly/vertex functionality through the feature script bridge. When I put in a feature request for this I was told poly tools are too low on the priority list.
Is it true that not enough people here are either dealing with scan data or needing to export quads?
Answers
-
I tend to find more people in need of triangle meshes. What application are you pushing to that needs quads?
0 -
Mesh processing is not something you can do with featuresript, the mesh definition is not exposed and highly abstracted. I believe specifically for performance reasons. Scripting languages are not good enough for running through millions of vertices or triangles, given that it has no parallelism. Better use some external tool, I've been using mesh inspector for quite a while recently on commercial basis, and its pretty great for what it cost and has mcp server for agentic manipulation and python api
0 -
I ran into this when I saw a model maker sanding out facets in a low res print. My mind went right to export preferences or mesh smoothing. There are solves for this but what I discovered is that OnShape does not convert to or export Quads. If you export quads many printer software packages and poly software like ZBrush or Blender can run button click tools to improve meshes. These tools are not effective if the whole mesh is all triangles. This also lead me to see that when a CAD software opens itself up to reverse engineering of scan data they need poly tools to support that work. Kicking all of that out and say other software can do that is a copout. Poly tools are the easy development. Dont sell workflows that you dont support.
0 -
Relying on quad geometry to smooth out your exports is sort of a bad idea because those smoothing methods rely on mesh subdivision, which changes the geometry of your part in favor of smoothness. Not an issue if what you're working on is a sculpture that doesn't care about precise dimensionality. Huge issue if you're sending functional parts with tolerances you'd like to maintain. That being said, the default options for mesh tessellation on export from Onshape are indeed horrendous for smooth prints, and I tend to set mine to some custom values for less visible artifacting on the final parts. Really the fix is to get 3d printer slicers to support .step files properly and not have garbage tessellators on the other end that result in the same chunky surfaces on import.
0 -
There are plenty of workarounds. Not being able to export in quads just exposes a bigger problem. If you are going to put yourself out there as a platform for reverse engineering scans you need basic poly functionality. I used to hear the same thing from Rhino. They put themselves out there as a Sub-D modeler without grown up poly tools. Releasing a purchased library without fully supporting it just pulled people in to see how weak their workflow offering was. They threw out all the typical copouts. If those excuses were valid they would not have ended up finishing all of those tools sets. They did. Same issue here.
0 -
Controlling the actual meshes has never been a standard feature in most CAD applications anyway, since the traditional workflow has always been to model in CAD and then clean up the meshes somewhere else, so it's quite understandable why they'd put it low in their priority list.
1
