Prevent model degrading to wireframe while orbiting, zooming

kurma · 11 Jul 2010, 13:08

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?

TIG · 11 Jul 2010, 14:16

Is you model near the origin? If not switch everything on and move things nearer to [0,0,0].
Make a Style for "general navigating" that doesn't have edge-extensions etc switched 'on', that has low appearance settings and that has no material textures switched 'on' [i.e. use plain 'shaded'] and no shadows switched 'on'.
Have multi-faceted objects [like trees] on a separate Layer that is switched 'off' whilst navigating.
Have the camera etc NOT fixed to the Style.
Have a Scene tab using that Style.
Then to navigate just switch to that Style and the go to where you want...
If you set another Style without the camera fixed etc butwith desired shadows, textures etc then switch to that when you are where you want to be - save views as other Scene tabs as needed.

kurma · 11 Jul 2010, 15:55

Thanks for the tips TIG. The model is on the origin and edge - extensions etc, were never switched on. I am quite new to SU so haven't played around with styles and scenes much. I use SU to design buildings for customers here in India - I used Rhino before but prefer the way SU does things. The default style is great for this and since I don't need to make fancy presentations haven't bothered with the other styles. Parts of the model degrading to wire-frame is not a big issue - I am just surprised it kicks in it way before my PC is stressed out, even to models it handled perfectly before. I was thinking it was a problem with my new notebook, but it has a decent graphics card - Ati 5870 with 1 GB dedicated - it should be able to handle a 12MB file. Obviously from your reply there isn't a simple setting to prevent the degradation or set a higher threshold. I doubt I'll get into scenes at the present time as the models handle fine apart from the degradation. Thanks again.

TIG · 11 Jul 2010, 16:33

You can try fiddling with your Preferences OpenGL settings

kurma · 11 Jul 2010, 17:32

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 · 11 Jul 2010, 18:04

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 · 12 Jul 2010, 06:34

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 · 12 Jul 2010, 08:18

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 · 12 Jul 2010, 09:26

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 · 12 Jul 2010, 11:05

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 · 12 Jul 2010, 12:54

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 · 12 Jul 2010, 16:45

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 · 12 Jul 2010, 16:55

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 · 12 Jul 2010, 17:08

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 · 28 Feb 2011, 01:15

@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