My hope is after reading this, we can build a list of "case studies", that describes the symptom, and tracks the ultimate resolution for that specific problem. These case studies will be posted in the table below, so users can find a problem and see how it was fixed for that specific user in their unique situation. -John Brock

Message from Jeff:

The basic problem is that the control settings are not designed to solve problems for a specific card. They're designed to solve specific display problems given specific symptoms. Additionally, they're not designed to work in combination with each other (IE. There aren't 2 or more settings that solve a specific problem). So, what fixes a problem for one user may not work for another, even if they have the same video card.

Having said that, get ready for some long winded descriptions about what each setting is designed for:

Use Accelerated Hardware Modes

Control location: Tools - Options - Appearance - OpenGL

This one is pretty obvious, but I'm afraid it's probably the most misused and misunderstood option. Basically, it toggles on/off the usage of hardware accelerated graphics modes. To be more specific: It toggles between using the hardware maker's ICD (Installable Client Driver) or using Microsoft's "Generic Software Emulation" driver.

Using the ICD usually results in much better graphics performance and more features and capabilities. However, it can also result in quite the opposite, and in some cases crashes, mainly because these ICDs are written by the hardware makers, and some of them just don't get things right. Additionally, there are major inconsistencies between the different hardware makers. Using Microsoft's Generic Software Emulation driver gives you 2 important things ICDs do not:

• A stable, unchanging, well tested implementation of OpenGL 1.1 functionality that's been around for over a decade maybe two.
• A consistent OpenGL implementation that exists on all Windows platforms (IE. it's the same thing, and yields the same exact results on every machine).

However, it's all done in software, which means it's usually pretty slow, and it doesn't support features found in later versions of OpenGL (1.2 - 2.0), some of which Rhino V4 uses (ex. Multi-texturing and blending of textures), and there will be quite a bit more used in V5 and beyond. Which is why I hate recommending this as a solution!

Turning off hardware acceleration should be a last resort (in most cases). Most likely turning off hardware acceleration will solve all problems, but it will also kill some nice features in Rhino, and really kill performance. If a user has a really nice graphics card (like a GeForce 7600 xxx or higher, or a Quadro FX 4600), then suggesting this option would be utterly ridiculous (IMO). Why? Because they're now getting the same functionality and performance they would get with a $10.00 cheapo card found in someone's junk drawer! Not only should this be unacceptable to the user, but it also makes Rhino look really bad.

If you find yourself reaching for this option, stop, and look elsewhere first.

• The only exception to that would be if Rhino is crashing immediately upon startup. If that is the case, you should have the user start Rhino in Safe Mode, disable hardware acceleration, and then restart Rhino. You're not done yet, and that shouldn't be the end of it. What you should then do is start looking at some of the other options, and then re-enable hardware acceleration to see if Rhino still crashes.
• If Rhino is still crashing, then you need to start considering driver updates and specific video card make and models. Please collect this information and add it to this Wiki.

The only time I have actually had to disable hardware acceleration is:

• Using Trident hardware found in some Toshiba Tablet PC's
• Using Intel 8xxxx onboard video chips. Note: The later Intel 950+ GL cards are actually pretty good, and support accelerated modes quite well, which brings me to an interesting situation. V4 disables hardware acceleration on initial startup for ALL Intel based chips. This means if a user has a 950 GL or higher, they're still using MS' Generic driver. However, enabling hardware acceleration for these chips will most likely help users, and in some cases solve problems (like slowness and updates), which is probably the opposite of what is currently being recommended or suggested.
• Crashes caused by ATI x300 cards when logged into Windows XP as a "Basic" user.
• Certain display characteristics are garbled or corrupted (ex. blotchy polygons, bad/incorrect looking transparency, etc.), in other words, a really bad ICD implementation.

I can't think of any other situation or card that I have here, where I've had to disable hardware acceleration to get things to work. If you have disabled this option, and don't meet the criteria above, then you probably did the wrong thing, or it might have been the right thing based your configuration (ie. something I haven't seen before or can't replicate here), in which case you should also start considering driver updates and specific card make and model (again, please collect this information). If you have completely exhausted all other options (without completely eliminating OpenGL altogether (ie. Windows Wireframe)), then it's probably OK to go ahead and turn off hardware acceleration.

If you do, then I want to know about it.

• I want to know: Video Card Make/Model, Driver Version, OS, Monitor count and resolution(s) used.
• I'd also like your contact information.

Use Hardware Environment Mapping

Control location: Tools - Options - Appearance - OpenGL

This one is really old, and I haven't really had to ever use it. It basically says: "Use the environment mapping mechanism that's inside the driver".

• Turning this OFF, means "Have Rhino use it's own emap mechanism". You should really only turn this one OFF if the you can't seem to get EMaps to work or look right. Then again, I've never seen this problem for the past 4+ years. This one I believe originated from some NT or Win98 configs. Neither of which are supported anymore. This one may be a candidate for removal in V5.

Redraw Scene When Viewports are Exposed

Control location: Tools - Options - Appearance - OpenGL

When you do something that changes Rhino's display, a message is sent to update all the viewports. Some display drivers will update the current viewport and leave the other viewports unchanged. This setting forces all viewports to be refreshed. It can slow you down so it sould only be used for this specific display problem.

Do Not Use OpenGL for Drawing Feedback

Control location: Tools - Options - Appearance - OpenGL

This one is kind of hard to interpret and explain. Before V4, all feedback display was drawn using Windows GDI. This caused problems related to flickering and wire alignment because GDI draws directly to the glass, and there is no way to get GDI to draw to OpenGL's backbuffer. So, the solution in V4 was to come up with as many drawing interfaces as possible in the engine definition so that all feedback could be drawn using the current underlying display engine. Thus, if OpenGL is being used, then OpenGL draws the feedback, if Windows GDI is being used, then GDI draws the feedback, if DirectX is being used, then DirectX draws the feedback, and so on. For the most part, and for most cards this all works pretty well. However, keep in mind that all feedback is drawn in every single view simultaneously. If you have 4 views, then all four views need to draw and update. If you have 6 views, then all six views need to draw and update, etc. as fast as they can, thus, this option was invented for one reason, and that was speed, or lack of speed, when drawing feedback.

Now let's suppose all views are using OpenGL (which is the default today). That means there's an incredible amount of blitting, drawing, and backbuffer swapping going on (not too mention context switches) in order to update all views. As I said, most mid-range cards or higher seem to be able to handle this, but for those cards or drivers that can't, what you end up with is lag or slowness when drawing, dragging. Basically any feedback, which eventually causes jerky feedback to a point where accurate placement or drawing becomes difficult. So, what this option does is it disables the use of the underlying engine (ie. OpenGL) and forces the use of the Windows GDI engine to draw all feedback. The end result is that you're now functioning like Rhino V3, but slightly better, no flickering due to triple buffering mechanisms.

You might ask: Why not just always use this?

• Because many of today's cards and drivers have no problem "keeping up" with Rhino's demands, and in fact, in most cases, using the OpenGL engine to draw feedback is much faster than GDI, especially when running on a 24" monitor at 1920x1200 resolution (where each viewport averages 900x600), which is larger than V3's default startup size of 800x600. OpenGL and the video hardware is simply much better at handling this stuff than Windows is.

What we have been finding is that some video cards/drivers also have problems (really implementation inconsistencies) supporting Rhino's feedback and triple buffering mechanism, and sometimes the feedback doesn't look right, or doesn't show up at all. Thus, enabling this option also solves those problems, but it wasn't really designed for that.

This option should only be used if you are experiencing feedback problems, and nothing else. It won't solve general display problems, it won't fix crashes (unless the crash happens during a display-feedback operation). Again, it might fix something that I haven't seen or thought of.

If you use this setting, then you should also be aware of the limitations it creates.

• Before V4, there was no command that attempted to draw "Shaded" feedback items. With the introduction of V4 and its conduits, this all changed, and several commands today use shaded breps and/or meshes to represent their feedback (some even use transparency).
• If you turn this option ON, then all of these command's feedback will come out looking like a solid blob. Why? Because GDI is being used, and GDI can not render "shaded" polygons, only unlit, solid color polygons.

I've used this option for the following:

• Trident video chips in some Toshiba Tablet PCs
• Intel video chips 8xxx or lower
• Some laptop models with poor throughput and/or fill-rates, which is really the bottom line here. You might have a really good video card running on a laptop that is poorly designed in the graphics pipeline, and thus has really bad throughput yielding bad fill-rates. Which means updating multiple OpenGL viewports in Rhino simultaneously will probably be a poor performer as well.
• Users who run in really high resolutions or use more than the typical 4-6 view layouts.

You're just going to have figure this one out as you go. Hopefully now you understand what it is doing, and why/when it should be used.

Use Region Buffers When Available

Control location: Tools - Options - Appearance - OpenGL

This option will be disabled in Rhino V4 SR3 and completely removed from V5. If you're running SR2, the first thing I would suggest is to turn this option OFF immediately. I would also shut down Rhino and restart before continuing. In fact, you might even reboot, because once the damage is done, getting back to a normal state might require a reboot. Keep in mind, this option is only available when region buffers are detected. Most of the nVidia cards support them, I think only the FireGL line of ATI cards supports them, and believe it or not, the Intel 9xx series supports them too. If the option is there and enabled, turn it OFF!

Region Buffers are used for only one thing, updating the screen/window with the contents of the rendered framebuffer. Garbage on the screen, parts of the screen not updating, or cursor trails during feebback operations, are all indicative of region buffer problems.

Switch Wireframe Engine from OpenGL to Windows

Control location: Tools - Options - Appearance - Advanced Settings - Wireframe - Other Settings

As I said earlier, the default configuration for Rhino is to now have all 4 views startup using OpenGL. Once we did this, one of the first things I started hearing from users was complaints about slowdowns, intermittent responses, and in some cases crashes. I eventually realized that it was due to this default change. We had users who had 32mb and 64mb video cards, where V4 ran just fine, but once we made this change, it didn't. The reason: creating multiple rendering contexts for each viewport was exhausting most, if not all of the video memory, was dependent on resolutions, and amount of available contiguous video memory. Thus, having them change the Wireframe engine to be Windows, reduced the amount of allocated video memory, and they were back to where they were before.

The only real reasons I can think of for even suggesting this option are:

• OpenGL just flat out doesn't work at all
• The user's video memory amount:usage ratio is non-optimal. I can't give you a fixed MB amount here because users with large amounts of video memory can still experience problems because they run at extremely high resolutions, and use 2-4 monitors.

Remember, this does not solve problems, it masks them. As soon as you get all viewports using OpenGL again, you're going to be right back to where you started prior to making this change.

How's that for a novel?

Thanks,

- Jeff

 Hi Jeff and fellow users

I have notice a serious slow down in between v3 and v4 and not just between shading and rendering but something as simple as layer display (for example if you have more than 30 layer names its really slow to select or turn on or off a layer)

I have two machines I use at work both dell Intel workstations; one with dual dual core xeon chips, the other with dual quad core chips both have 512 mb quadro fx 4500 card and 4gigs of ram.

Both machine become painfully slow with any file over 10mb in size. I can take the same file export to 3d max when I set the display to open GL its slow as well (relatively the same as rhino). When I set the display to direct-X no problem it moves along just fine with no display lag. This leaves me wondering about Open GL . I have a dual AMD x2 at home and it acts the same in Rhino and 3D max in regards to open GL and Direct-x. in all scenerios im using one monitor. I think this is a real problem and not just trouble shooting.

-Thanks Will