Prevent model degrading to wireframe while orbiting, zooming

TIG

You can try fiddling with your Preferences OpenGL settings

kurma

I am using the default - hardware acceleration and fast feedback. I'll mess around with the settings in the Ati control panel - didnn't really want to do that just for SU. I am still left wondering why models degrade when they were fine before (all others things being equal)? Still a terrific program.

sorgesu

TIG mentioned "materials" in the style settings and maybe you didn't catch that.
That could be a biggy.

Materials could create a great deal of overhead by requiring SKetchUp to recalculate the perspective representation of the brick and roofing etc in perspective as it orbits. If you change the "face style" setting to just "shaded" instead of the default "shaded with textures" you may find an improvement.

BTW: what is way too soon? You don't have a lot of repetitious trees or curvy things in place?

kurma

By way too soon I mean that my system can easily handle all the textures on the model that SU sometimes degrades. For example there is a crowd test model that I found to check my system - increasing the scene level adds more people until the model degrades. But once that happens scenes with many less people which were orbited perfectly before will also degrade. And it's not that orbiting or zooming was difficult or jerky at all, they worked like a dream. So why would SU do that? Anyway it's a minor annoyance to a marvelous program.

In future I would like to see a setting to allow the user to decide the balance between performance and quality.

baz

I experienced something simliar to this a while ago with what I thought was a small model, but I had a google earth snapshot (with contours) hidden which I'd forgotton about, plus quite a few deleted components. Delete and purge worked for me.
Might be worth a try.
baz

kurma

That's why I downloaded the Crowd Test model. It's very simple - just lots of 2d people. There are several scenes - each with an increasing number of people. And nothing else.

I am now curious if others are experiencing the same - please try the 500kb Crowd Test. I can sometimes get up to scene 10 before seeing any degradation when orbiting (zoomed out to just include the whole crowd). After that dropping down to scene 7 still has signs of degradation.

If you do post results please include system specs. And after reaching your limit gradually drop down to the lower scenes to see if or at what scene the degradation disappears.

My notebook specs are

i7 720
Ati 5870 with 1gb
6gb 1333 ram

baz

I've just tried the crowd scene, no probs to scene 10, then partial wireframe at scene 3 when revisiting. Bit weird that.

intel 4. 3ghz
nvidea 6400gt 512mg
3gb ram

baz

Jim

There is a "tipping point". I think SketchUp checks the response time for orbiting, and adjusts the delay accordingly. Once the tipping point is reached, there is no going back.

In SU 7, there are some Ruby methods which control some aspects of this degradation, although I don't know their specific meanings:


Sketchup.max_draw_time
Sketchup.max_draw_time=
Sketchup.full_detail_render_delay_min
Sketchup.full_detail_render_delay_min=
Sketchup.full_detail_render_delay_max
Sketchup.full_detail_render_delay_max=

(At least I think that's what they are for.)

kurma

baz - thanks for confirming the behavior.

Jim - in Sketchup 7.0 the lower scenes in the Crowd Test are not affected once the tipping point is reached. But unfortunately that version of SU is much less optimized and really degrades my textures so I'll not be downgrading. I did a Google search using the info in your post - there's nothing on "Sketchup.max_draw_time", but I did find an interesting site when searching "Sketchup.full_detail_render_delay_min". The whole performance issue is covered very nicely there although nothing that solves my problem. I did try changing the values of render delay in the Ruby console (once I knew the default values) but it didn't improve orbiting in the Crowd Test.

Chris Fullmer

There is also an LOD (level of detail) setting somewhere. Either in the API or perhaps it is a constant? Jim, I forgot how to list all the constants. I was trying main.constants, self.constants, and things like that, but so far I can't rememeber how to get a list of them. So how do I do that again?

I just thought I'd look those over in case there was something in there that dealt with the LOD.

Chris

EDIT: got it! Objec.constants and I'll sort them out and read through them and report back if I see anything intersting.

Chris Fullmer

Well, I certainly did not find anything intersting in the constants.

I guess maybe I was rememebering the View.dynamic= method. But that seems to be useful only within a script?

http://code.google.com/apis/sketchup/docs/ourdoc/view.html#dynamic=

bentleykfrog

@unknownuser said:

This kicks in way too early - often on models that the camera could previously easily orbit, zoom without degradation - is there a way to disable it or adjust the settings?

In the preferences dialog under OpenGL, disable "Use fast feedback" to stop components degrading to a wireframe representation of their bounding box on camera movement. Disabling this will also increase your view refresh time. I think that both "full_detail_render_delay_min" & "full_detail_render_delay_max" both relate to the fast feedback setting wrt wireframe bounding boxes? Regardless of the fast feedback setting, textures will still turn off and on based on the "full_detail_render_delay_min" & "full_detail_render_delay_max" settings.

-niall