Creo 2.0 Drawing Performance Issues

[BrianMartin]

Hi Everyone...

I have to be brief but... does anyone else have really bad performance issues in Creo 2.0 when working on a large assembly? Build code can be M040, M050, or M060. It doesn't matter all three are similarly bad.

I have a 4-sheet drawing with a rather large assembly. There are tons of "lines". Simple operations like zooming in/out, moving a view, and even just selecting an object are taking forever. I've tried every trick I know and it's as slow as it can be. When I click a dimension to move it and Creo takes 5 second to select the dimension, that's bad.

Imagine this scenario... I need to more a tiny detail view a few inches to the left to make room for something else. I move to the view... 3 seconds later, it highlights. I click the view... 4 seconds later, the drag handles activate. I hold down the mouse button and drag the view... then let go of the button to drop it. Creo takes 20 seconds to move the view and repaint. Moving a view just took 30 seconds.

Now imagine I have 100 items to balloon and dimension... and pages of details yet to complete. What the actual *! $^#( is going on? Just a simple zoom isn't possible. I roll the mouse wheel... 2 seconds later the view updates. I roll again... one little notch on the wheel... and 2 seconds later, the view updates.AHHH! I'm going to lose my mind.

Oh- here's a neat trick... activate the Merge Balloons tool... and suddenly the views zoom normally again. So now when I'm zoomed in tight to a detail and I need to zoom out a little... I hit a mapkey to activate the Merge Balloons tool and I can zoom around again. Then I deactivate the tool and go back to work.

Any ideas? Similar experiences?

Thanks!

-Brian

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.

[JamesBurcham]

I had a similar experience. My issue was that my parts had tens of thousands of features, so regeneration time was slow. Its possible you are having the same issue. We spent plenty of time working with PTC, but the only real solution was more computing power.

[BrianMartin]

Hi James...

I'm working on a brand new workstation with 32GB RAM, a 2GB graphics card, and screaming processors. I wish I could chalk this up to processing power. The trick with enabling the Merge Balloons tool seems to suggest that greater speeds are very possible... but that something inside the Creo code is causing the slowness.

Oddly though, usually processing bottlenecks do show up at regeneration time. My model regenerates quickly... but the drawing is just like running in molasses.

Thanks...

-Brian

[TomD.inPDX]

Brian, you are likely dealing with the GPU regen issue (not considered an issue by PTC). Even on a very simple model, I can get similar behavior.

Turn down the shade quality; turn off the textures; turn edge quality display to low; and turn off anti-aliasing.

Even if you don't have shaded views, I suspect the GPU regen goes through the entire file to refresh its filtering index. It seems to be rebuilding the entire polygon database between every command.

It is almost like we need to go back to the limited CPU days where we have to turn off views to make it interactive. Oh, yes, that too may help get the ballooning done.

[BrianMartin]

Thanks Tom...

I'm not using any shaded views on the drawing. In fact, I tried adding a few to see if the shaded graphics performed better. In model mode, shaded models have traditionally been the fastest. Well, unless you want to go back to the way things were in 1995 when wireframe was fastest.

When I turned shaded views on... things got exponentially worse! I've already tried several of the options you've suggested. I didn't consider messing with the shade quality settings or texture settings because I'm only doing "no hidden" views.

I also hadn't tried Danilo's suggestion (below) because the preselection didn't seem to be the core of the problem. Once I had already selected something, it still took forever to move it or to right-click to work with the object.

But... since you guys brought these issues up, I went hog wild and turned off every single shade option I could find and the preselection highlighter. What do you think happened?

Total failure, right? Amazingly... it sort of worked! The only problem now is figuring out which of the 25 options I just toggled had the greatest impact. I wouldn't call the performance impressive or anything... but it's usable which is better than wasting hours tediously messing with this drawing.

I'll see if I can isolate the problem...

Thanks for the suggestions!

-Brian

[TomD.inPDX]

Shading is only an artifact of how PTC has been doing graphics processing since inception. Everything graphic is done through the facet model. This is what give you "no hidden" views and shading at the same time. This is from the now archaic VRML world. So whenever there is a "regen" of any kind, it rebuilds the facet model.

So here is part of the rub, even if your high quality image of the model regen's quickly, it does so for every view in the drawing when in drawing mode. And this creates a selection index which becomes "HUGE" because it is picking "through" the facet edges which you never see. I certainly hope it doesn't propagate through all the sheets as well. That would be dumb!

I suspect you will get better performance if you also use your selection filter. If only we knew exactly how the selection code was working. Part of all that focus on 3D annotation has really left the core detailing functionality in the dust. I worked on one model with textures that was absolutely intolerable. All that was wrong was the display quality set to high. Medium and low was exponentially faster.

The hint that gave me this idea is how large the files were when saving models with high quality settings. Every single faces, including LOD levels were being saved. This makes each part huge when creating filtering indexes too. PTC has simply lost their edge in managing their graphics engine. What has always been a easy way to manage GPU cycles has become a liability. And the code people have simply ignored this overhead hoping the graphic engine guys would keep up. Guess what... it didn't happen!

I don't know if PTC is taking this issue seriously. This is starting to cost clients money in productivity. We can only hope that people like yourself can force a corrective course through the right channels.

[dveljkovic · Accepted solution]

Brian, try to deselect "enable preselection highlighting". Maybe Creo is trying to preselect detail below the mouse pointer hence the wait.

[BrianMartin]

Hi Danilo...

Wow... believe it or not... it was the stupid preselection highlighter! I don't know if I would've even considered that. I toggle it while working on models but I never tried it in a drawing. It's usually so useful in a drawing that I never thought to turn it off.

This is the first of the 25 switches (mentioned in the reply to Tom) that I tried toggling to isolate the 'culprit' option. It's crazy that the preselector was causing the problem. That led me to think a bit more about the problem. Why would Merge Balloons also seem to solve the problem?

Then it all made sense... when Merge Balloons is active, your selection filter is set to exclude everything except BOM balloons. I went ahead and tested this theory but changing my selection filter from General to "Snap Line". This also increased my speed. In fact, setting the filter to anything but General did the trick.

With General active, the preselection highlighter is looking for all object types. In a drawing with 10,000 lines and annotations, it's getting overwhelmed. By narrowing the preselection filter's choices, you can keep it on and still speed up your drawing work. For the fastest speed... turning it off on large drawings is the answer.

Thank you Danilo... really!

And sincere thanks to everyone who replied. Usually I answer the questions but this was a welcome change. Plus, I finally get to award points to someone for a correct answer!

Have a great weekend everyone!

-Brian

[dveljkovic]

Brian, you are welcome. I am dealing with these things all the time - every time. In model mode I usually use "datum" filter (instead of unchecking the preselect option) so Creo does not start filtering through parts, edges, surfaces and-who-knows-what-else trying to preselect while I am manupulating with models. Of course, show-plane button is off. And it helps. As for preselect option, there should be an option to use it when some defined key is pressed, like CTRL or ALT or both. In other cases it should be off. We had a macro that was switching preselect option on of off but we do not use it anymore. Have a nice weekend to all.

[TomD.inPDX]

Thanks from me too, Danilo. There seems to be a bug in the pre-selection highlighting too. It often turns off by itself for unknown reasons. When modeling, it is annoying when it turn off. At least this is the case with M040. Looking forward to installing M070 this weekend.

Again, nice catch! I'm sure I will be using this tip in the future.

[dveljkovic]

You are welcome Antonius.

[Patriot_1776]

I can see this, I have turned off preselection highlighting since it was first introduced (I query/select everything), but leve highlighting on in the layer and motel tree........except when I have dwgs with very complicated views (tons of lines), then I have to turn it all off, especially the layer setting.

[gkoch]

Yes we had a lot of complains about drawing performance being very bad and it mostly was due to pre-selection highlighting.

Actually this was on by default in older versions as well (Creo Elements/Pro 5.0 for example).

But what has changed with Creo Parametric, is that the default selection filter in drawing mode has changed from "Items and Views" to "General".

In contrast to the old default, "General" includes all model geometry as a possible selection, e.g. all edges - which can be quite something to highlight.

Besides this: Some improvement to graphics speed is expected by the new config.pro option in Creo 2.0:

fasthlr_drawing yes

[James62]

The setting fasthlr_drawing yes will make thread lines/semi-circles on threaded holes dissapear from drawing views.

[Patriot_1776]

Hmmm, well THAT's not an enhancement..... I was all set to change that option. Thanks for the warning Jakub!

[James62]

You're welcome, Frank.

I've just started to move all my settings to WF4, about a week ago, and I am gonna start testing it on real projects soon. I've already figured out that the Remove feature that I use so much works pretty much the same as in Creo 2.0. Also WF4 seems to be operating so much faster.

[dveljkovic]

Gunter, this option fasthlr_drawing=yes changes my drawing from this:

to this:

[gkoch]

Unfortunately I can only confirm Jakub:

Cosmetic threads never have been supported for fasthlr (not in 3D and not in 2D, which simply makes use of the 3D capabilities).

I have updated article CS3269 in the PTC knowledge database accordingly with the information from the related SPR (which is currently with Product Line Management, to be considered as a possible enhancement in a future version):

https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS3269

So it seems the option is only useful while working on the drawing, but not afterwards, when printing it.

Regarding Danilo's finding, that the colors appear in hidden and no hidden line mode (wireframe works correctly, showing black lines and shaded is supposed to show model colors):

This error has been recognized and will be fixed with the next build, Creo Parametric M080.

See article CS121497 : The 'drawing view property' 'Colors come from' set to 'the drawing' does not work when the config.pro option 'fasthlr_drawing' is set to 'yes' in Creo Parametric 2.0

https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS121497

[dveljkovic]

Gunter, one more thing. With this option tuned on, text, that is on one detail, is visible on drawing, although it is behind blue detail. You can see yellow text below blue detail which should not be visible.

[gkoch]

Hello Danilo,

I even found a report on this topic (against 3D mode in Wildfire 4.0, not against 2D views in Creo), but the only suggestion was to use the setting fasthlr no.

We need to bare in mind that PTC development is optimizing graphics display in terms of performance since 25 years. Unless modern graphics hardware allows to delegate more work to the graphics boards (which will again trigger hundreds of angry customers claiming "regression" in the new release, because it does no longer work with their old machines - I can tell from past experience!), performance gains are hardly possible without simplifying or even omitting some calculations.

So better performance will always be bought at the expense of quality and vice-versa.

The idea behind fasthlr originally was to enable faster display of the model while working with it.

That it was not available for drawing views, might origin from the thought that nothing below best quality is accepted for drawings.

But of course while working on a drawing, performance might be more welcomed than (temporary) quality, so fasthlr has now been made available for 2D, too.

To finalize and review, one can always switch back to regular display mode, if necessary. So nothing is lost, it is just another option for alternate behavior with its advantages and disadvantages.

[dveljkovic]

Gunter, thank you for reply. I do understand issues PTC might have. But if fasthlr does not work as it suppose to in 2D why bother even to make it available? Imagine I open something with fasthlr enabled. This means, I can look at the prints in 2D, I can manipulate it, but when it comes to printing I will have to close Creo, disable fasthlr (for 2D), open Creo again, open the 2D file and print it. Am I correct with this statement?

I think, that with smarter filter selection by default and prehighlight on, we can

As for new graphics card, OpenCL is clearily available to all AMD cards and nVidia has CUDA. So why not use these options? How hard is to port programming code to work with OpenCL and CUDA as GPU-accelerated applications?

I just cannot understand why my AMD V7900 is just a little faster than my laptop's Nvidia 550M GPU. This tells me that Creo is not optimized at all nor it uses all capabilities of graphics cards and CPU's. I have no other explanation for it.

[James62]

Nope, Danilo.

That option isn't just gonna eat the thread lines or any other lines that are supposed to be in the drawing, at least as far as exports of the drawings are concerned.

But it's confusing, indeed.

[James62]

Gunter,

The option fasthlr_drawing yes applies to regular holes, and as far as I can tell these don't have cosmetic threads, but regular surface-like or better said quilt-like threads. These quilts show up in the model if fasthlr for models is set to yes.

This is not an unfortunate behaviour, I think it's perfectly fine, cause as you've mentioned all linestyles from the drawing print as they should into pdfs, and also export into dwg files, etc.

The only thing that is unfortunate here is the description that is given as on the following picture.

While we are at it, I would like to know what is for example the fast_highlight option good for, as well as hlr_for_quilts, because I doubt the desription of these is anyhow accurate.

These could just be bugged, but who can tell?

[TomD.inPDX]

This thread is probably the only hint I've ever received about fast HLR. Gunter, your history lesson is the best tit-bit of information -ever-. This really gives me pause as why these things are not more "transparent" in working with Creo. Sometimes we complain about the barrage of warnings we receive... but when performance switches are turned on, ones that -will- affect the final product (the print), a note, with sufficient reference!... would be welcome. Also knowing the behavior when plotting and printing would be very helpful.

Maybe while HLR is being investigated they could pass this onto the doc's, UI, and help teams at the same time.

Again, thanks for the very clear definition of the -intent- of HLR.

[KeithMarriott]

Hi I guess that this is a realtively old post now but I am new here. I would just like to point out that you can toggle fasthlr for drawings on and off using the View tab, there is a button on there. You can set your default to on or off using your config.pro so at least there is no need for a mapkey or restarting CREO as suggested by Danilo.