[teistiz]

Hi, I'm new to this board.
*tries to dodge bfgreen*

So this shimmering thing (very noticeable on the Orion at least) finally got annoying enough to actually make me try and see if I can fix it. After looking around this forum for a while without finding anything, I got the source code from CVS and started going through it.

Looks like the source code as of 2006/03/11 doesn't include any real mipmap generating functionality, at least for .dds textures, and is set to disable trilinear filtering when no mipmaps are available. Since the .dds files in mv_textures.vp (at least the 3.6.8 delta version) don't include any mipmaps either, the Enable Mipmapping option in the launcher doesn't do anything. I think this is what's causing the shimmering effect.

Anyway, I tried extracting the .dds files from mv_textures.vp with vpview32 and re-saving them WITH mipmaps into the data/maps directory. I used a program called "DDS Converter 2" (just google for it). And whoa, did it make a difference. I'd post screenshots, but the shimmering is most noticeable while moving, and a static image or two wouldn't really show much.

Doing this probably increases VRAM usage quite a bit, but it didn't seem to have any effect on FPS on my box (AMD64 Venice 3000+, 1024 MB RAM, Radeon X700 Pro w/ 256 MB).

Is there some particular reason (except the increase in file size + vram use) for the lack of mipmaps in mv_textures.vp?

[taylor]

They should be coming with the next MediaVP release.  I already have all of my textures converted to have full mipmaps so I missed out on most of the shimmering problem.  Someone really needs to fix the Orion model to use the textures properly (where mipmaps are concerned) and that will help the problem as well.

Automatic mipmap generation still doesn't work for OGL, but this is rather strategic at the moment.  It can help but mainly just wastes memory at this point.  It's going to be enabled automatically when -img2dds is used (with an upcoming patch), but -mipmap probably still won't do anything.  I might change my mind on that (again) but for now it's the direction I'm going.  Anything but the newer models don't use mipmaps correctly (they use different LOD textures plus mipmaps) and this really just messes things up.  When more people are doing the right thing model wise I'll clean all of this up to do automatic mipmap generation again.

[teistiz]

Ok, thanks for the info.

Looking forward to that next release 

[Muriac]

Hmm. When I opened this thread, I expected it to be about the zbuffer. Is not everyone having the texture flickering (rather than shimmering) problem? I can see the shimmering issue, but it's far less noticeable than the zbuffer issue. Any word on solutions to that? It seems to me that the range of distances rendered by the FS engine merits a deeper zbuffer. Is that just wishful thinking on my part, or is it at all likely to be implemented? Or do I have the problem/solution all wrong?

[taylor]

I played around with the zbuffer distances but didn't get much in the way of good results.  Are you modifying the near and the far distance, or just one of them (ie, -clipdist)?  What values work the best for you?  I haven't really been keeping up with the Mantis bug on this which is why I ask.

[teistiz]

Oddly enough, I can't recall seeing any z-buffer errors / flickering in fs2_open for a long time. But now that somebody mentioned them, I'm sure I'll notice them next time

I've been looking into the automatic mipmap generation. Turns out there's an ogl extension that can do just that.
Tried forcing the code to always use trilinear filtering, and then adding this to the opengl_create_texture_sub function in gropengltexture.cpp:

<code>glTexParameteri (GL_TEXTURE_2D, GL_GENERATE_MIPMAP_SGIS, GL_TRUE);</code>

This caused some slowdown in larger battles, probably because it generated mipmaps for _everything_, including backgrounds, explosions, shockwaves and other things that don't really need them. But it worked
Is there some clever way to detect what the texture's going to be used for in this function? Maybe this extension could be useful.

EDIT: Most likely this only "works" because it bypasses the some stuff by leaving the mipmap_levels-variable's value at 1. It's still cool

[Muriac]

I played around with the zbuffer distances but didn't get much in the way of good results.  Are you modifying the near and the far distance, or just one of them (ie, -clipdist)?  What values work the best for you?  I haven't really been keeping up with the Mantis bug on this which is why I ask.

I didn't realize you could modify the far distance, but that would probably break missions like Into The Lion's Den, where there are ships 150km away. In any case, increasing the near clipping distance does have a positive effect. Values of 4 or 5 reduce the problem to the point of being almost unnoticeable.

The only thing is that the near clipping plane, even at its default distance, clips things that you run into head-on. Increasing the the near clipping distance (obviously) makes this problem worse. Ideally, I'd like to be using a -clipdist value that is lower than the default. In order to do that and still fix the flickering problem, there would have to be another fix.

[WMCoolmon]

I did some dynamic clipping distance stuff based on object position, but IIRC beams presented a serious problem for it, that I wasn't terribly motivated to try and solve. You'd have to basically figure out the farthest and closest point of the beam onscreen.

IIRC that work is turned off by a #ifdef or several in CVS.

[Muriac]

I did some dynamic clipping distance stuff based on object position, but IIRC beams presented a serious problem for it, that I wasn't terribly motivated to try and solve. You'd have to basically figure out the farthest and closest point of the beam onscreen.

Is that a terribly processor-intensive task?

Also, was this dynamic clipping distance done per-object, or per scene?

[WMCoolmon]

per-scene basically. I doubt it'd be extraodinarily processor-intensive, unless you had a crapload of beams onscreen at once, it was more the maths thing that drove me to keep from completing it.

[Backslash]

Nice idea teistiz!  Inspired me to try a bunch of stuff as well.

Anyway, I tried extracting the .dds files from mv_textures.vp with vpview32 and re-saving them WITH mipmaps into the data/maps directory. I used a program called "DDS Converter 2" (just google for it).

Just a note to those who are interested in such things... DDS Converter 2 is nice, but it uses an older version of nvDXT to convert files.  The latest version of nvDXT has some floating point optimizations and a new switch, -quality_highest , that makes a big difference in quality -- way less compression artifacts.  (Unfotunately, DDS Converter 2 can't use the new version )

Of course, nvDXT is a command line app, so anyone unused to such things may need to stick with GUI programs.  In that case, ATI's Compressonator is worth checking out.

To test my claim of better quality, I reconverted the TGA planets in mv_advanced and compared them with the DDS planets in mv_effects... noticable difference.  If you want to see for yourself: http://www.qeyleb.net/files/PlanetsDDS.rar

[DaBrain]

Very very interesting! Thanks for the info. I'll give it a try.


Edit: It's really true. The quality is a bit better, but it's not much and it depends a lot on the maps...

Sadly the ATI tool isn't as userfriendly the DDS Converter is...

[Muriac]

per-scene basically. I doubt it'd be extraodinarily processor-intensive, unless you had a crapload of beams onscreen at once, it was more the maths thing that drove me to keep from completing it.

Wouldn't it work almost as well if you just used the beam's start and end points? Beams usually aren't too long, are they?

Oh and the math to do it properly is just an equation to find the two points where the beam intersects the four planes that make up the viewing area, right? I haven't done trig in a long time, but someone around here must be good at it (working with 3D graphics and all).

[neoterran]

using a supersampling / multisampling mixed mode AA will also help fight this. (for example, 4xS, 6xS, 8xS modes)