Is there a way to "de-feature" parts in assemblies for improved performance?

brian_brady

I have noticed that some largish assemblies get very slow. I have been able to hide some parts that have a lot of detail and keep working , but I don't always want to hide parts while working. Is there a way (or can there be a way) to reduce detail or "de-feature" specific offending parts? For instance, one assemble had a set of THK slide rails and carriages that were imported from their website. These were fairly detailed, but did not need to be most of the time while performing assembly tasks. I would like to tell OS to reduce detail in the assembly so fewer surfaces needed to be calculated as the assembly view was manipulated. I know that I could just buy a newer computer with a faster, more capable graphics card, but that is not the solution I am hoping for.

Brian

Paul_J_Premakumar

@brian_brady

 We try to automatically reduce the detail of parts, but there is always room for improvement. Can you please log an enhancement request? Thanks for the suggestion!

3dcad

I wish for similar feature especially with more complicated imported objects like say fully detailed cnc-machine on layout assembly. Onshape should automatically reduce details that are not visible in current zoom level (I suppose it already does that) but I might also like button 'performance mode' which would lower details signifigantly while zoomed back.

john_mcclary

I agree, They may already have an algorithm in place. I'm referring to Progressive Graphics

https://www.youtube.com/watch?v=eVBeKJRcjc8

maybe they can add a slider to an assembly that lets us set the final level..

owen_sparks

This would certainly be of interest here.
 
To my mind there are 3 elements for improved performance:-

(1) Hardware.  Sure OS runs on any device with any operating system and by users wearing any colour socks, but we can do our bit to help by using the best hardware within our budgets.  At work we've just upgraded from machines that drew 19 Million triangles per sec to ones that do 380 Million.  Once the model has loared or rebuilt the difference is imense.  But only after, which leads to...

(2) Modeling sensetivity.  Sensetive to load that is.  I'm guilty of building stuf that has big long chains of derived features and now I'm regretting it.

(3) OS features.  Providing we've done our bit as above then all that's left is to let OS build upon their sucess and find new ways to help out.  I love the idea of defeaturing but wonder how much this is relevent in parametric modelling?  Sure in rendering, but in modeling don't we need to have the software work things out exactly?  Would building and then de-featuring actually add load?

Cheers, Owen S

brian_brady

john_mcclary said:

I agree, They may already have an algorithm in place. I'm referring to Progressive Graphics

https://www.youtube.com/watch?v=eVBeKJRcjc8

maybe they can add a slider to an assembly that lets us set the final level..

I don't think that is what I am after. Progressive Graphics seems to only be in effect during load time. I was thinking of right-clicking on a part and selecting "reduce detail" so that something like a bounding block is shown instead of the fully detailed part to speed manipulation and regeneration time.

Brian

john_mcclary

@owen_sparks

as for #2) Yes, it is good practice to not over feature your derived parts. But sometimes when you download a purchased part it is over featured. And you're at the mercy of the vendor, or you have to redraw / modify it. I mean how necessary are all of the fillets on extruded aluminum   Or in my case an engine block casting.

as for #3) That's the hope I'm dreaming of, We see the whole feature is the derived part studio. We have control of how much we really want to cram into one part studio, but not really the case in the overall assembly.
But the top level assembly could be de-featured based on, either a slider or something. That should only affect graphics, which would leave all of your parametric features intact in the part studio, just not rendered in the view.

It could get complicated... but I've dealt with enough customer parts that just destroy a model performance with all of their fillets. It would be a huge time saver to be able to limit the features a bit.

3dcad

I think software should take care of performance and let us create highly detailed stuff.. If you gona print your part you need to have those fillets in place or maintain two versions of each part. Same goes with vendor models and fixing each new version you get while on process.

bill_daniels

I agree.  Many vendors provide 3D CAD models with ridiculous levels of detail.  I have one model of a linear motor containing nearly 1700 highly detailed parts. Every screw showed detailed threads.  I could use this model to manufacture the motor myself.  What were they thinking?

Paul_J_Premakumar

@brian_brady

 We try to automatically reduce the detail of parts, but there is always room for improvement. Can you please log an enhancement request? Thanks for the suggestion!

billy2

We would always make a simplified representation as a configuration and then force that to be the loadable configuration when opening an assembly. You could always switch to a fully detailed configuration later. Maybe we need configurations for this operation. I have to say though that maintaining the configurations was a real pain. They always seemed to become decoupled. Not sure this is the best way to handle the 2 display states as the assemblies migrate up to the top level.

I'm not sure a programmer can define these states. I think I want this control.

Downloaded parts should always be reviewed before using. McMaster Carr's bolts are horrendous, that helical sweep showing the threads is nice looking but kills the graphics card.

De-featuring a part is easy, just draw an extrusion over the violating geometry. Then suppress the extrusion when you want to see the pretty part.

This was a 1.3mb download. Can you imagine using 1,000 of these in an assembly?



One thing that wouldn't be hard to do, and you wouldn't have to mess with configurations, is to dance through all the features in a feature manager and suppress features named '%simplify%'. It could be a toggle that changes the state of the part/assy from high resolution to low resolution by clicking on something. All you have to do is type "simplify" in the features name and the script would know to toggle the feature's state. This is much simpler than managing 2 configuration states.

In any CAD system, I don't care if it's cloud or desktop, you have to manage large assemblies and their display states.

Computers just aren't fast enough and they're not getting any faster. We really need to manage what's on the screen. We need to make things go away and then come back easily.

Object_Mage

Just export it then import it as a new part

mahir

@billy2, I agree with the use of simplified configurations for assembly purposes. That's what I think @brian_brady should be using - maybe label the config "for Assy" or something. Simplified configs are somewhat cumbersome to implement, but I don't think having an algorithm that automatically suppresses anything tagged %simplify% would work out any better. It's not any easier to manually tag a bunch of features with metadata vs manually suppressing certain features in a configuration. Maybe if the tagging process were somehow magically automatic... but I don't know how that would work.

john_mcclary

mahir said:

 Maybe if the tagging process were somehow magically automatic... but I don't know how that would work.

That's the problem, there is no way to teach a computer what "you want" or "how simple is too simple?"

@billy2
Use a "delete face" feature to remove unwanted threads, if you want them in a config it's 3 clicks away to add suppression state check box.

everyone:
At some point we as designers and engineers must actually think for ourselves and use our better judgement to create our drawings to suite our specific needs. I don't understand why people insist on the CAD system to be smarter than us. In my experience when a computer makes an assumption to help you out it usually is the opposite of what you want. example, Microsoft office auto correct / auto format. Can't tell you how many times I have exported a fastener list to excel just to find all the "3/8-16" fasteners are called out as "March 8, 2016".
Look at solidworks feature recognition. Good in theory, better off ignored in reality.

Edit:
I have half a mind to copy paste the delete face command and name it "Defeature Part".

bill_daniels

owen_sparks said:

This would certainly be of interest here.
 
To my mind there are 3 elements for improved performance:-

(1) Hardware.  Sure OS runs on any device with any operating system and by users wearing any colour socks, but we can do our bit to help by using the best hardware within our budgets.  At work we've just upgraded from machines that drew 19 Million triangles per sec to ones that do 380 Million.  Once the model has loared or rebuilt the difference is imense.  But only after, which leads to...

(2) Modeling sensetivity.  Sensetive to load that is.  I'm guilty of building stuf that has big long chains of derived features and now I'm regretting it.

(3) OS features.  Providing we've done our bit as above then all that's left is to let OS build upon their sucess and find new ways to help out.  I love the idea of defeaturing but wonder how much this is relevent in parametric modelling?  Sure in rendering, but in modeling don't we need to have the software work things out exactly?  Would building and then de-featuring actually add load?

Cheers, Owen S

This got me thinking.  Some of us have really powerful hardware but it seems as if running OS in Chrome isn't taking full advantage of it.  Maybe there could be a user selection of how much workload to assign to the client system and how much to assign to the 'cloud'.  Those with weaker hardware could assign most work to the 'cloud' to lighten the workload on their systems while those with beefier machines could take on more of the load.

Somewhat related is when using Ubuntu's System Monitor, I've seen a change in how Chrome/OS utilizes multiple CPU's.  In the past, my 8 CPU system would "baton pass" work from one CPU to another with only one CPU working hard at any one time.  Now, I'm seen episodes where all are working together at up to 50% but there is still some "baton passing".  Interestingly, when using other hardware-intense applications, I see all CPU's taking on equal loads.

Cheers, Bill D

Jake_Rosenfeld

Hi @bill_daniels

A couple thought on this:

The first concept you mention is something that is coming slowly back into style right now called "Edge Computing": https://en.wikipedia.org/wiki/Edge_computing.  Our style of offloading the graphics display to your computer is one style of edge computing. Many other pieces of software use a more "Cloud Computing" approach to graphics: the images are generated on the cloud and then send to your computer frame-by-frame.  We found that that solution is laggy and frustrating to use, and chose a better way to proceed.

That being said, most of the rest of what is going on in the cloud would be hard to migrate to the edge.  As a specific example, it is of great benefit to us (and to our users) that all of our geometry processing servers run on the same type of virtual machine in the cloud.  This type of software is particularly sensitive to the machine it is running on, and if we had to compile it for every possible device we want to run on it a) would probably not be feasible for mobile/mac/chromebook and b) would create slightly different geometry on each of those machines.  This slightly different geometry would break our effort to guarantee that your geometry looks the same way on every device every time you load it up.

There's a lot of nuance here, but you are definitely correct that there are probably areas where we can leverage the user's computer if they have a powerful machine.  We are always keeping an eye out for the best way to implement different technologies.

As for your second question, for a program to take advantage of multiple cores on your computer, it must use multiple threads of execution: https://en.wikipedia.org/wiki/Multithreading_(computer_architecture) . Until recently, web programs were limited to being single threaded, in other words, web programs could not "fork" additional threads to take care of processing on the side. There is a newish technology called "Web Workers" that allows work to be offloaded to additional threads: https://www.w3schools.com/htmL/html5_webworkers.asp .  In some ways, web workers are weaker than traditional multithreading in non-web languages, one example is limited support for sharing data between threads.

owen_sparks

john_mcclary said:

everyone:
At some point we as designers and engineers must actually think for ourselves and use our better judgement to create our drawings to suite our specific needs. I don't understand why people insist on the CAD system to be smarter than us. In my experience when a computer makes an assumption to help you out it usually is the opposite of what you want. example, Microsoft office auto correct / auto format. Can't tell you how many times I have exported a fastener list to excel just to find all the "3/8-16" fasteners are called out as "March 8, 2016".

Couldn't agree more with that bit.

john_mcclary said:

Edit:
I have half a mind to copy paste the delete face command and name it "Defeature Part".

@billy2
Use a "delete face" feature to remove unwanted threads, if you want them in a config it's 3 clicks away to add suppression state check box.

I think some care is needed with workflows / terminology here.  You're probably way ahead of me but just in case:-

(a) If you take a complicated part and then de-feature you're adding to the complication. (With our parametric timeline / feature tree the rebuild process is to import in fully complicated state and only then run the delete face stuff to make it simple = lots of work for OS to do and then some more on top...

(b) I presume you mean import as complicated, de-feature, re-export as parasolid, and then use afresh from the parasolid?  That way the complicated bit is taken out of the rebuild each time the part studio is opened?

(c) For the configuration you'd suppress creating the threads, not the removing of them? (On the assumption that not building them saves time, building and then deleting them does not.)

Cheers,

Owen S.

john_mcclary

It is all about the assembly instances that will show the performance gain.
By the time they make it to an assembly they are solved parasolids in memory. The feature tree (should) not affect rendering in a large assembly, as they are only rendering the surfaces remaining in the solved parasolid. So to have a very complicated part, then delete a face may take longer for the initial calculation. but you will have exponential performance gains where it counts in assemblies.

In order to defeature an imported part the system would need to do extra work to "recognize features" then provide the user with a list of available features to suppress. Right now (correct me if I'm wrong) the import is just creating a solved parasolid of each body in the input file, and storing the result in parts.

----------------
To anyone at Onshape who is elbow deep into the code of the import function: After you import a step file for example, Onshape will automatically render the part into a parasolid only once (correct?).
if that is true than a delete face would be calculated each time you open/read the studio into memory.
So 1 or 2 additional features to delete a thread for example should still be quick.

(Not to be confused with Modeling a thread in native Onshape, then using delete face, which would need to do extra processing to create then delete the faces)

I'm curious to know how close (or far) I am from understanding how Onshape's import feature 

Uh oh @philip_thomas almost let that lowercase "o" get through! Good thing I added it to spell checker

philip_thomas

OK - late to the party - but here goes.
Lots of good conversation here and most of you are spot on.

That said - here are my nuggets

• Graphics card is critical - (meaning you need one). If https://cad.onshape.com/check reports anything other than your graphics card (read it carefully) then you need to start troubleshooting there.

• Derives are a mixed bag. I use them a lot - they are very useful - BUT - If the parent needs updating, it can lead to longer regen times (and at a minimum, once every 3 weeks when we release (and invalidate the cache)). Later in the design cycle, moving part studios out and deriving from a version/revision is the fastest if the design has reached a certain level of maturity. Lastly - if you want to derive 2 parts from a single Part Studio, do it in ONE derive and not TWO (twice as expensive).

• Part Detail level - I went through an exercise of de-featuring a LOT of parts in a VERY large assembly for a customer (and as a good exercise for us to learn from). Bottom line - NOT WORTH IT. As the face count drops (simplification), the level of tessellation increases. After days of work, I had 30% fewer faces and performance (rendering/rotation) was exactly the same. Its not a tessellation problem. With the new 'level-of-detail' capability, you can force lower levels if thats what you want. The real hit comes with drawings - sectioning and performing HLR on a very large number of faces (and threads), takes time in any CAD system. If you have read this far deep into a paragraph of text, your reward is that I have played with assembly configurations and it will be a very good solution for drawings - giving you the ability (for instance) to suppress fasteners or simply change the LOD for complex parts. This is a standard practice in many CAD systems and Onshape will offer the same.

• While we are talking about drawings - making drawings of versions/revisions is far faster (when opening and switching to).

• Variables - It looks really nice, but instead of putting them at the top of the tree (regens the entire feature tree on every change) try to introduce variables only when you need them.

• Monitor the regen times of your Part Studios (stop watch icon). Sort by time taken. If there are any glaring culprits - chances are there is a better or alternate way.

I may add more later - these are off the top of my head

mahir

philip_thomas said:If you have read this far deep into a paragraph of text, your reward is that I have played with assembly configurations and it will be a very good solution for drawings - giving you the ability to suppress fasteners or simply change the LOD for complex parts. 

Assembly configurations you say?

philip_thomas

Well, at least I know that someone reads my musings! Yes, they are very good
(still a lot of work to do - you know the routine, we release when they're ready)

brucebartlett

I read it @philip_thomas and jumped for joy. The first thing I was thinking about this morning after getting up was how assy configurations will solve some of my current assembly issues and whether I should put off my current project a little, or push on with multiple branches and time-consuming mate switching. I will have to push on without them but really can't wait.

On the defeaturing, I like the idea of cleaning up a part exporting and re-importing but I don't think you get any performance improvement over just linking back to a version.  Linking back to versions seem to give great improvements but doesn't always suit my workflows in design development when you still want things to be fluid. 

On fasteners, I had a project where a lot of un-edited McMaster parts were used with threads and all. I was a bit disappointed the time hadn't been taken to edit these but didn't really see a hit in performance in this particular case and it is really handy having the threads to ensure correct engagement and the head marking so you know it's the correct bolt. 

philip_thomas

@brucebartlett

Glad you're excited - I know we are.

Yes linking to a version is as fast as the export/import round trip

Yes defeaturing doesn't do much except in drawings (and will be much more efficient with, ahem, you know what)

I am hoping that you are making standard-parts docs with all your McMaster parts;

• Make two configs (one defeatured) - use the same naming convention throughout
• Make these 'non-rev managed' or use revisions (not versions!) - reduces (or prevents) the 'newer version exists'' message
• I am not sure yes how this will all play out (we are still writing code), but a custom property 'purchased' might be useful.

You and I have tech call coming up, we can talk more then