Monday, February 2, 2009

SpaceClaim Response to My Topology Review

SpaceClaim requested the part that I used for the History-Free shootout in my last post. I sent the part to them along with the move positions and they quickly sent the following response. Thanks to Blake Courter of SpaceClaim for taking the time to do this.

As I mentioned in the post, I was moving the features only using the default settings and options, for all three systems. Blake points out here that there is an easy option in the Move function of SpaceClaim to solve some of the more complex topology problems. Since history-free modeling features do not have a “recipe” associated with them to tell them how to behave, it is important for the history-free system to offer options such as what SpaceClaim is showing below. This can provide more flexibility for managing the possible results.

Below are Blake’s comments and images


Hey Paul,

Here are my findings on your part. I did use our Detach First option on most edits, because this option is optimized for longer walks across topology.

#3: It seems that when all three are moved the exact same distance, we get a slightly different result. This did not show up when I wasn’t using your test part.

#5: Everything works beautifully with Detach First on.

#6: Everything works beautifully with Detach First on.

#8: I didn’t see any order-related problems.  With Detach First, we get holes in the top fin, which are easy to fill.

#9: Everything works beautifully with Detach First on.

#10: With Detach First on, we get holes on top.  Easy to fill. Otherwise they stay put.  This is a great example of why we have the Detach First option.

#11: With Detach First on, we get holes in the fin, but there doesn’t appear to be any order-depended problem.

#12: We get a different result with Detach First on.  Another great example of how the option helps.

#13: Cool thing with Detach First: the holes leave surfaces behind so you can move other objects and then reuse the surfaces to make the holes again.

R&D tells me that the default behavior is even smarter with our next release, but I think that the important points are:

  • It is easy to make all of these edits.
  • Topology changes are usually ambiguous.  Even if you don’t get exactly the result you expect, it is easy to adjust the given result into the one you want. 
  • Some of the issues you had appear specific to your test part, and we suspect they are less likely in the field.


No comments: