cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily. X

Creating perfect circular dimple (cut) on a circular surface (ring)

ptc-5136585
1-Newbie

Creating perfect circular dimple (cut) on a circular surface (ring)

I have a ring and on the surface of that ring I am trying to create a perfect cicle dimple cut. The problem is that since the surface I'm trying to cut into is circular the round dimple turns into an oval. Is there any way to make this feature so that looking down on the ring, this dimple looks like a perfect circle? Here is a picture of the ovular dimple on the ring.

example1.jpg

Hopefully I've explained myself.

Thanks


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
43 REPLIES 43
TomU
23-Emerald IV
(To:TomD.inPDX)

This probably needs to go in a new topic, but I just finished extensive testing of several different model display settings and their effect on file size using WF5 M120, WF5 M160 and Creo 2 M050. I used the same part this thread discussed, but around twice as long with more dimples. Here is a summary.

  • "Smooth Lines" has no effect on file size.
  • "Shade Small Surfaces" no effect on file size.
  • "Edge Quality" has some effect on file size.
  • "Shade Quality" has a HUGE effect on file size.
  • The "save_model_display" config option does not work as documented.
    • WF5 M120 & M160
      • "shading_low", "shading_high", and "shading_lod" all create the same size files.
      • Basically the "low" and "high" versions seem broken are track to display settings instead.
      • Setting "save_model_display" to "wireframe" works as documented and creates consistently small files.
    • Creo 2 M050
      • "shading_low" seems to be working correctly now. File size is small and consistent regardless of display settings.
      • "shading_high" seems still broken since the files sizes sizes change with different display settings.
      • Setting "save_model_display" to "wireframe" works as documented and creates consistently small files.

I have attached a PDF copy of the test data. What becomes quickly apparent is that, depending on config and display settings, file size can range from less than 1 MB to over 46 MB for the exact same file.

Something else that may not be obvious. If "save_model_display" is set to wireframe, when the file is previewed in Pro/e or opened in Product View (Creo View) it will only be visible in wireframe mode. If the file was saved with "save_model_display" set to anything else, then preview and Product View can display the model all four ways (shaded, no hidden, hidden, and wireframe). Also, the active display mode when the file is saved has no bearing on what is stored in the file.

TomD.inPDX
17-Peridot
(To:TomU)

WOW Tom, you rock!

Indeed this deserves a Document open for discussion.

For those that don't know, LOD means "levels of detail". This has to do with managing GPU cycles but it means that you literally have 4, 5, 6... different versions of the display saved in memory and the zoom state determines which one is passed to the graphics processor.

The fact that you found the Low, High, and LOD version to be identical is significant. Someone at PTC really should look at this. In fact, PTC should look seriously at this whole issue as being a problem. I know "why" they are doing it (JT file manipulation), but their implementation for the rest of us is seriously flawed. We, in general, want a very simple, low detail graphic so that previews process very fast.

If nothing else, a warning should be generated when your file is about to be saved with "significant" graphics data; significant being when the graphics data exceeds "pertinent" data.

BTW: this is the very reason I complained about Creo M030. That release really highlighted this issue. If this was managed better, I would have never known. Which is the point, isn't it?

TomU
23-Emerald IV
(To:TomD.inPDX)

The one that really made me choke was when I saw the file size in Creo 2 with "shade_quality" set to 50 (the new high limit).

771,043 KB !!!

That means a file that's under 1 MB when all features are suppressed, and around 8 MB with the out-of-the-box display settings grows 98 times the size to over 771 MB with the shade quality cranked up all the way. Crazy.

TomD.inPDX
17-Peridot
(To:TomU)

True, and how many of us do just that when we want a good screen print! This is what caught my attention in the 1st place.

I know about LODs from VRML development. Virtual worlds were big about a decade ago. LODs kept slower computers interactive as you moved through worlds. Today we know VRML formats as facet files. The LOD determines the size of the polygon to represent a surface. JT files are VRML on steriods in capability. None the less, they are facet files written into the part/assembly files. These are what PTC uses to create advanced assembly techniques and light graphics. Managing this within an organization that uses these techniques is critical, time -is- money. But for the majority of us to know the "right" way to use it is not common knowledge.

...and the takeaway I get from your extensive research tells me that the best way to avoid the overbloated file size is to set the save_model_display to wireframe and you can use the every day setting to your heart's content without worrying about settings when you save. Interesting enough, -most- previews in the file-open dialog still show shaded as do does the thumbnail option. not sure of the full ramifications and that is why an open discussion could bring more data to life.

TomU
23-Emerald IV
(To:TomD.inPDX)

Just to be clear on the lods discussion, for all the testing I did the config.pro option "lods_enabled" was set to "no" (the default), and the hidden config.pro option "lods_value" was not set, meaning it should have automatically been at the default value of "50". The config.pro option "save_bitmap" was also set to "none". For what it's worth.

TomD.inPDX
17-Peridot
(To:TomU)

That is a good clarification. Indeed, the interplay with the setting is not clear. What really blurs the behavior on save is how some things are maintained in the file and others are not. So if the LOD is turned off in the current session then the system has to pick a default for creating them on save if that is what it is set to.

Please create a discussion on this and include relevant posts from this thread maybe as quotes. I would really like PTC to create a matrix diagram to show us the interplay in all these settings. Somewhere there -has- to be a logic diagram.

Patriot_1776
22-Sapphire II
(To:TomU)

Excellent data, thanks!

F

If its just an aesthetic feature you could;

- profect a circle onto the surface as a guide

- revolve an ellipse which you can then adjust till it matches the circle

- set the revolve axis horizontally in the above image and offset from the surface

There are ways but obviously the feature won't be a spherical dimple.

I might try a variable section sweep. you can project a circle onto the surface and use that as a trajectory. Take a look at the arc dropdown in the sketch, you can pick a conic from there for the profile that varies with the sweep, or you could enlist an ellipse.

Any way you could show me an example of what you mean?

Sure, I will work on one. What version are you using? Academic or full?

I'm on full. I'm actually on WF4, but I do have access to Creo pro 5.

I am on Creo 2, but the idea is the same. I will make a video and post it later.

The variable section sweep can be a bit tricky. I got it to work but I found a patterning bug I need to report.

round_dimple.PNG

Top Tags