UT OpenGL commands?

Sounds like we may have to wait for Chris to get his new web site going and to mention the changes for V3.5. Right now, yes, it looks like some changes were made for UT to run better with OpenGL on ATI cards and there may be some UTPure and U4E bugs if you play online. Actually, I think I'll wait for that unless he wants to post the change log here.

Just to avoid confusion, those are commands for the D3D9 section and NOT OpenGL (although most of the commands themselves are similar). This is a note to anyone not already familiar with this thread.

Looks like I have no problems with the UTGLR OpenGL version 3.5 for now! Everything looks great and plays great!

I made some slight changes to my INI file post above similar to Unreal changes, but the only thing changing from here on out will be AA and AF once I decide on the levels.

I decided to do the same for UT as I did for Unreal and change the AA/AF to 8X/16X for now until I do some detailed testing.

EDIT: just for the record, I decided not to do the detailed testing.

UTGLR Version 3.6?

Anyone try this yet (released 11-16-09) and have any idea why a lot of the commands were removed in this version? I know a lot of them on Chris' page say "set internally now" but does that mean the game does it automatically or the drivers or what? Thank you.
http://www.cwdohnal.com/utglr/

"Changes in version 3.6:
- NoMaskedS3TC option removed. Always uses RGBA DXT1. This matches the only option for DXT1 in D3D.
- GL_NV_multisample_filter_hint extension support removed. Don't consider this one very useful anymore.
- A few 227 editor related updates that were general renderer code fixes.
- MaxLogUOverV and MaxLogVOverU config settings removed. These are set internally now.
- Larger default maximum allowed texture size in the not using S3TC config case.
- Potential NVIDIA driver bug workaround for the major graphics corruption after windowed / full screen switch issue. Suspect this may be fixed in newer drivers now, but was easy to add.
- RequestHighResolutionZ option removed. Modified code to attempt to get a 32-bit, 24-bit, or 16-bit z-buffer in that order.
- If first mipmap pointer set to NULL in SetTexture(), skip looking at others.
- AutoGenerateMipmaps and AlwaysMipmap options removed.
- UseDetailAlpha option removed and always enabled internally. A number of detail texture rendering paths depend on having this one enabled.
- BufferClippedActorTris option removed and functionality it controlled always enabled internally.
- A few other minor changes.
ZRangeHack will be enabled by default for UT if not already present in the ini file, but this one may still need to be watched a little more closely. There are a couple cases I know of where it has minor side effects. However, with most video cards these days only supporting 24-bit but not 32-bit z-buffers, or unless modified other parts of the game engine to draw decals a little further away, it is needed to avoid decal flickering in the distance in many common cases."

Anyone encounter any bugs in Version 3.6 yet?

Here's Chris' response at the OldUnreal forums:
"Mostly cleaning out a few old options with little to no reason to have configurable. Removing the AA filter hint / Quincunx option a bit different in that it was more a feature cut, but I've only had an increasing number of reasons to want to finally pull that one. The latest being a combination of wanted it gone before looking into supporting alpha to coverage for masked textures (in case might be any odd interactions between this and the post filter across any number of possibly different configurations for these features that NV may have implemented across various hardware), and vendor specific functionality tends to be more costly to support long term in general (and this method I see becoming increasingly obsolete as time passes).

If really want this one enabled I'd have to say just use application profiles through the control panel, which should still make it usable without too much add complication. I haven't kept detailed track of when NV has been dropping old card support in their drivers for things like GeForce 3 and 4, but I know they have per app profiles in their old control panel, so I'd expect it covers a fairly wide range of hardware and likely as far back as the first to support Quincunx.

So many other reasons I don't like Quincunx, but didn't care so much about leaving the option around until looking at other things dealing with subpixel samples like alpha to coverage and selective multisample disabling (post filter pulling in further away subpixel samples can interfere with this), where then more concerned that it might have the possibility to interact with other things in bad ways. Eventually I've been hoping less reason to resort to using a blur filter due to performance considerations now that newer hardware much faster in general along with other improvements more specifically related to multisample support. Don't like the edge blur behavior in many cases, but also have the issue of Quincunx causing general texture blur for interior not edge areas.

The NV multisample filter hint extension didn't really seem to go anywhere as far as other new feature support in this area goes, and unless running with fairly old hardware now, there may be better options such as hybrid supersample and CSAA that currently could only set through a control panel override as far as the renderer goes. Looks like the NV_framebuffer_multisample_coverage extension added for CSAA for the OpenGL side, and ways to get to some of these through D3D, though seems to sometimes differ a bit across different versions of the API, and need to use odd hacks in some cases.

But when considering all the different ways to set the various special AA modes now across the different graphics APIs, and all the hardware that would need to have to be able to have test coverage across all of them, I start liking the idea of leaving everything except basic / standard multisample to application profiles a lot more."

I spent so much time tweaking my latest UT install with all the OpenGL commands with version 3.5 that I'll just run 3.5 for a while longer before I switch. I'm sure it will run fine with WinXP SP2 32-bit though.

I think I'll just wait until I get a new system with new hardware and install UT again before switching to V3.6. Anyone know when OpenGL version 3.6 will be upgraded to the most stable version of UTGLR?