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.
Is there a limit to the number of features in any one part studio before performance falls off?
npennycooke
OS Professional Posts: 4 ✭
I have a part studio that has a large number of parts, and a larger number of features (since the only way to reference other parts is create them in the same part studio), and it's at a point where I can't work on it anymore. It takes about 20-30 seconds between, for example, drawing a rectangle and being able to interact with it or constrain it in any way. For every single operation, the spinning clock in the corner comes up causing something that should take only a few seconds require several minutes to complete. Even pressing 'N' to shift to a normal view can take upwards of a minute.
In other part studio tabs, things move quickly as expected, without any hiccups. Is there a limit to the number of features OS can reliably support in any one part studio? If so, why not allow users to edit parts in the context of an assembly studio so that one part studio doesn't have to be loaded up with hundreds of features for parts that require references to each other?
Is there any way to alleviate this?
In other part studio tabs, things move quickly as expected, without any hiccups. Is there a limit to the number of features OS can reliably support in any one part studio? If so, why not allow users to edit parts in the context of an assembly studio so that one part studio doesn't have to be loaded up with hundreds of features for parts that require references to each other?
Is there any way to alleviate this?
0
Answers
I've been working on this mold base inside OS (259 components).
So it's fairly good sized model:
This file came across as a parasolids and there are no assembly structures, it's just one large part studio.
Both SW & OS struggle with this file in it's current state and I'm breaking it down into groups/sub-assemblies to manage the data I can show on my screen at any one time. This will make this manageable.
Instead of forcing the CAD system to display everything in my design, I tend to work on strategies that'll allow me to make things go away and come back. I want my system to be responsive and tend to organize my data into manageable chunks that I can turn off/turn on. At the end of the day when I want to print out the overall, the system takes more time to render.
Knowing how 3D CAD works helps when designing large assemblies. There's 2 parts to a CAD system: the display, the geometry. That pretty shaded image you look at takes 50% of resources. Geometry creation occurs during a rebuild (and on a server in OS), the rendering of your design is done on your computer. Rendering is done both on your CPU and graphics card. Rendering is a big deal for OS (all CAD systems).
The image is based on polygon count and being mindful of this can really help your large assembly performance. Having configurations containing simplified representations of parts is a good strategy to manage your display (can't be done in OS). I tend to just delete unwanted features that cause high polygon counts (can be done in OS). In my assembly above, they used Mcmaster Carr bolts with helicoil sweeps all over the place. Helicoil sweeps create a high polygon count to represent a bolt. I usually extrude a cylinder over the Mcmaster Carr sweeps to reduce the polygon count. My first group that I created contained all the bolts which I hid. The system became extremely responsive after turning these off.
The time to open an assembly is based on the display list coming over the internet. Keeping your polygon count down will help. Understanding your geometry will help in that a plate represented by 6 analytic surfaces and 12 polygons renders in no time. Rendering a helicoil sweep takes a lot of resources and to represent a bolt, to me, is a waste of time. I back out all of that stuff from my designs to keep things responsive.
I've played with many large assemblies in OS looking for ways to setup means to manage the datasets displayed on the screen. I like it, I can reduce and manage what's on my screen easily. I don't see this as an issue after setting my large assemblies up properly.
I'd be interested in your design, if you can share an image I'd be happy to offer my suggestions to manage it and make it more manageable.
Since I've started working on it again this morning, I'm not seeing the slowdown at all. What I'll do is keep both open for most of the day and see if it gets progressively worse (likely pointing towards a leak issue). If it does, I will submit a ticket as I see it.
@jakeramsley Understood completely. I should have framed that as a suggestion and not as "why isn't this in yet". Excited to see where things go from here.
@bIlly Unfortunately we can't post up images of the project on the public forum right now. When it comes to rendering, I don't have any unreasonable hiccups with panning/rotating or model display. It's only when I try to do an operation such as sketch/feature creation or measuring a line or distance between planes. Over the past few weeks I too have been breaking things down into more subassemblies to manage things a bit better, and that has helped make it easier to work in assembly studio. I'll definitely keep these things in mind as the assembly grows and when we move on to other products.
Also to close the loop on the original topic of this thread, there is in-context editing for a few years now.
I've worked in proe carseat models that had 4000 features. To regenerate that whole model took forever. But, once regenerated, working within a feature (the sketch) or creating a new feature is normal speed. OS is definitely different in that regard. When it starts to slow down, everything seems to slow down, even brand new super simple features.
I've contacted support many times for help in speeding up my models, and they were always super helpful and had good suggestions.