Extrude up to body, up to face, booleans, performance

S1mon · February 9

With Parasolid and FeatureScript performance in mind, I'm trying to figure out the best approach to creating a lot of features which a normal user would use "up to next"/add.

As a regular CAD user, with things like bosses and ribs on injection molded parts, whenever I've been working complex models for a while, each extrude "up to body" seems to make the model slower and slower. My theory is that the trim edges for the complex surface becomes that much more complicated over time, and whatever searching over the topology happens internally goes up exponentially with the number of intersections.

In FeatureScript, in the interest of finding the correct targets and simplifying the end face for extrude up to, I've been trying to use a lot of raycasts, and sometimes fitting a plane to make a flat analytic thing to extrude to. In some cases extruding just a little beyond that plane, so there's definitely an overlap.

Is this a waste? Should I just always be using "up to next"? As an end user, I've found there are times when extruding just past the target and booleaning that can perform much better than things that are theoretically touching.

What's the best way to analyze this? I know there are timer calls I can do. What's the right way to profile FS code?

Konst_Sh · February 9

One thing to try is to make one single target set of faces or surface retrieved from opSplitBySelfShadow of the target body. Use it for all extrudes and then merge them to target, or extrude everything blind/through all, and trim with that tool before merging with target

S1mon · February 9

https://forum.onshape.com/discussion/comment/126671#Comment_126671

Very interesting idea. I searched through the std library, and opSplitBySelfShadow doesn't seem to be used any where. rib.fs does some Boolean intersections of stuff that's extruded blind to a distance based on the bounding box and throws away the bad bits.

Any examples of public features where opSplitBySelfShadow is used?

Konst_Sh · February 9

Hm, I'm not sure about examples, but it's a narrowed version of opSplitByIsocline with zero isocline angle and handy return of grouped side face queries

S1mon · February 9

I definitely understand the concept. Early in my career, I did surface modeling in Pro/E essentially that way. Up until late in the CAD model, there was a set of core side surfaces and and a set of cavity side surfaces. It was much easier to do a much of surface merges (includes the trims) for internal features like ribs and bosses that way.

Any thoughts on tracking time to profile performance?

GregBrown · February 9

https://forum.onshape.com/discussion/comment/126675#Comment_126675

Have you tried the built-in profiling tools? https://cad.onshape.com/FsDoc/debugging-in-feature-studios.html

EvanReese · February 10

@S1mon not a direct answer to your question, but one way to go about a feature like this is to make sure your major steps are functionalized. That way you can start with the easy-to-write function, and later swap it with the long-but-optimal function later without breaking everything else. That way you can get to MVP level with the feature faster and only fix things that annoy you upon real use.

Derek_Van_Allen_BD · February 10

@EvanReese I struggled with this a lot with my sheet metal feature implementations. There are a lot of easy intuitive ways to do sheet metal features that are abysmal performance hogs to the end user. Right now I've got a janky implementation of a stitch bender feature that I'm holding off on deploying because the project it's intended for already has a 120 second rebuild before adding the feature and I'll easily add another 60 seconds to it if I don't optimize beforehand.

EvanReese · February 10

@Derek_Van_Allen_BD Yep if you're already sure you have an issue then optimize now. It could even lead you to abandon the feature or start from scratch if your original idea proves to not work. My point is that I prefer not to solve problems I haven't proven I have when the downside is small (the feature is a little slow)

S1mon · February 10

Premature optimization is bad practice. What's even worse is thinking you're optimizing something but you're actually doing it in a more convoluted slower way. Without having actual data, I made some bad assumptions.

I am running into some edge cases with extruding with draft that have driven me nuts, but I'm also learning - thanks to @GregBrown 's suggestion - to use the FS profiling tools. That led me to realize that although I assumed that a few raycasts and extruding to a plane might be faster than extrude UP_TO_BODY, it doesn't seem like it. Raycast is oddly slow.

S1mon · February 16

@GregBrown

One thing that's particularly frustrating about the profiling tools is that there's no way to extract the information from the side bar or expand it. I have to scroll left/right to read anything. You can click on each item, and the editor jumps to the function call in question, but there's no good way to copy this data into a hit list of stuff to work on.

These are 3 different functions, but because of how they're named, it's tricky to see the info:

If I scroll to the right, then I can't see the timing info:

(one could argue that the naming could be abbreviated to account for this limitation, but should we have to?)

The performance tab also only covers regeneration performance as far as I can tell. There's no built in way to see edit function performance (e.g. why is my manipulator drag so sluggish?).

Any other hints?

Extrude up to body, up to face, booleans, performance

Comments

Howdy, Stranger!

Quick Links

Categories