GL graphics artifacts/errors

[safemode]

This thread is for all the GL issues going around. This is not a thread for how you'd like things to be.

Please, only post issues with the high or very high detail mode. I have to fix the other modes.

I'll start off with a post of my own issues. I'll group them by artifact = small visual error, error = large visual error, performance = unacceptable performance but otherwise looks correct.


Error:
problem:
Load saved game menu from main menu displays a series of verticle white lines. This is with the latest nvidia amd64 linux drivers on a 6600 card. Problem did not occur in old 100. drivers.

Investigation:
Besides driver rollback, we're trying to look into what size and format the files in that menu are. Initial checks seem to indicate that they're all fine. Next we have to investigate the GL options used to display that menu in particular. UPDATE: Problem was a bad DDS file.

Resolution: Resolved.


Performance:
Problem:
When a unit fills the majority of your screen (be it a base or planet) the framerate drops to half of what it is when there is space and only distant units filling the screen. This occurs even when you're stationary. This is with both Very high and regular High detail mode and has occured since I first started working on VS. Video card is nvidia 6600, using nvidia's drivers.

Investigation:
Initial checks indicate an increase in cpu usage when framerate drop occurs by over 30%. for instance, if cpu usage was 30-40% before, now it suddenly becomes 70%, with no change in action, just an increase in the filling of the screen of the unit. Drop in framerate occurs even when framerate is locked to vertical refresh, and with quality settinsg turned way down. Occurs on High, very high and medium detail settings. I suspect some type of manual blending or mucking of texture data when a unit takes up a lot of the screen, or maybe that mucking simply becomes overwhelming in that situation. Or perhaps a GL setting that doesn't like my card.

Resolution: Not Resolved.

[loki1950]

good idea safemode

another nvidia 169 issue weird filling in the jump animation
not VS but PU we are using the current engine the devship is solid white the texture appears to be dropped completely

and several of the gas planets have funky false colors
hope nvidia fixes that driver soon but i suspect we may need to poke them as the only other game with problems is UT2k4 Coragem mentioned that in one of his posts about the driver problem.

Enjoy the Choice

[Coragem]

I confirm i have the same two issues safemode reported.
Other than that i can say VS is very stable GL wise.

[safemode]

good idea safemode

another nvidia 169 issue weird filling in the jump animation
not VS but PU we are using the current engine the devship is solid white the texture appears to be dropped completely

and several of the gas planets have funky false colors
hope nvidia fixes that driver soon but i suspect we may need to poke them as the only other game with problems is UT2k4 Coragem mentioned that in one of his posts about the driver problem.

Enjoy the Choice

Make note if you have "High Performance" texture quality setting enabled in Nvidia Control Settings. High Performance will corrupt many textures we use. You must have at least Performance, level set. Quality or better is fine too.

[loki1950]

Thx will try that in XP atm though.

Enjoy the Choice

[loki1950]

Well tried with High Quality and this is the result




about the same it was set to Quality before

hope there is some clue as to what is wrong

Enjoy the Choice

[safemode]

strangely it looks like the load saved game screen. Maybe this is a good clue as to what is wrong.

[safemode]

I fixed the load save game issue. It was a bad DDS file. I suspect the same for your whole crazy red/white space issue. The problem is, space backgrounds are not DDS files. So some other image that gets overlayed or something i'm not thinking of, is doing it. It's going to make it extremely hard to track down.

can you describe your graphical issue more clearly? Does it happen in every system? Does it happen only when looking at a certain thing? Does it happen right away or only after some time? Does it happen when docked?

I wouldn't worry about the planets color until we figure out why the entire screen is getting jacked up.

[loki1950]

This particular one happens at all jump point when you jump so it is the jump animation that is corrupted in some way.

Enjoy the Choice

[safemode]

Coop beans. I'll make the fix when i get home. If someone doesn't beat me to it. It's almost certainly the same thing that was wrong with the load save game screen. The DDS is corrupted in some way. All that is required is recompression (from the master).

[safemode]

I've discovered that the problem lies in the nvidia driver. It's a driver bug introduced after 100. It basically makes rendering the DXT5 data generated _ONLY_ by nvcompress to be corrupt. Generating DXT5 data via the gimp-dds plugin (which uses GL to compress) results in a valid file.

We have a couple choices here.

I can compress all the semi-transparent textures that would require dxt5 with gimp-dds and replace the current nvcompressed textures, or we can leave them png and have them be uncompressed. I vote gimp-dds, with a marker set on the forum to remind us to try and re-use nvcompress when the driver gets fixed.

DXT5 is only needed when we have semi-transparency. FULL transparency, or FULL opacity can be done better with dxt1. By full transparency, i mean that the alpha layer is all 100% transparent. basically, if the alpha layer only has nothing or black masking dxt1 is good, if it has grey, then you have to use DXT5.

The wormholes use full transparency, so they're better compressed by dxt1 anyway.

Edit: I think only textures that have a dimension equal or greater than 1024 are affected by the bug.

[ace123]

Is it possible that they tried to hack around their broken compress program?
What happens if you use the unpatched version of nvcompress?

However, I don't think it's really a viable option to recompress everything just for an nvidia bug. That's a lot of changes that would have to be made.

[pyramid]

Not sure in which cases we are using DTX5 compression. As for my contribution I did the planet textures (greater than 1024px dimension) with DXT1 since the are completely opaque. The shields, armors, and planet hud are using DXT3. The reason is that nvcompress only has options for DXT1 (-bc1), DXT3 (-bc2), and DXT5 (-bc3) and dtx3 was sufficient for this purpose, though I can agree that DXT5 compression is better. (Here is a nice comparison of S3TC algorithms: http://en.wikipedia.org/wiki/S3_Texture_Compression)

For compression I was using nvcompress 0.9.x with safemode's patch. Has anybody tried if version 2.0 has the same problems?

I have mentioned it already in another post: I'll put up a wiki page during the next days to list all requirements for all types of imaginary (it's partly already there but for planet textures and cargo images only).

@safemode. From your post I get that it' s_ONLY_ textures with
* 1) DXT5
* 2) by nvcompress
* 3) with dimensions > 1024px
that give problems. Which one's are they?
The warp files are all 256x256 so maybe all resolutions are affected.

Summarizing the discussions to put up the requirements on wiki:
* Opaque textures/images must be DTX1 and can be compressed by either nvcompress or gimp-dds (in any resolution)
* Transparent (or semi-transparent) textures/images need to be compressed as DXT5 and with gimp-dds (any resolution).

[STEVE555]

Hi to all,
After updating my SVN version to the latest,recompiled,and also getting the latest updates for xserver/xorg updates for my distribution,almost all the artifacts that I was suffering previously have gone away.The only artifact I'm seem to be getting now are the gas giant planets still have the alternating white lines.I'm still using the latest 169.09 drivers from Nvidia,and I do still re-compile the driver whenever I get a kernel or xserver/xorg update.

I too wish Nvidia will be releasing a new driver soon(at least a beta,the last beta driver was released last November)I have put a post on the NVForums sometime ago,with the relevant logs that they needed.

I would like to thank the developers with making great strides to try and fix the problem.

Regards,
STEVE555

[safemode]

alright, so all resolutions are affected. :-/


I tested out texture-tools svn. it compiles without a crazy patch, but for some reason it falsifies the colors of a texture. I think it's using "fast math" and screwing things up when gcc compiles it.

I used llama_bodyBUMP.png to test. My patched texture tools compresses it perfect in dxt1. svn of texture-tools screws it all up.

I'll go ahead and try the 2.0 release and see if that is affected too.

texture-tools 2 does support dxt1a too. so if it works, it would be great to switch to that to encode the textures, since compressing to dxt3 wont lead to as high of a compression as dxt1 if the only reason for using dxt3 is the alpha channel support (for flat alpha's).