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).

[pyramid]

As announced, here's the wiki page Development:Graphics Requirements.
It will be updated as the requirements change.

[safemode]

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.

A lot of the dxt5 images should have been dxt1a (or we remove the alpha layer and make it dxt1), nvcompress prior to 2 did not allow this (gimp-dds does). We would benefit from smaller filesize and smaller memory footprint by making as many images as possible as dxt1 or dxt1a. This means trying out nvcompress 2 and seeing if it messes up the colors. So it's not _entirely_ just to work around an nvidia bug. The bug just made it that much more important to fix a mistake that existed anyway. There aren't that many dxt5 images in VS.

Also, we cant make every ship bump/damage/regular/normal texture png. That's going to use a rediculous amount of ram when most units actually get them. We need to nip this in the butt now, before it becomes a massive change.

Every uncompressed 1024x1024 texture is like 8MB on the video card. Unacceptable. If we have a serious problem with the pixelation of DDS files for these special textures, then we need to use another RGB mode that uses less bits per pixel.

[loki1950]

Thx safemode the worm hole animation now works with out the artifacts but found an other one of pyramid's here's a screnie


the VDU nebula image.

Enjoy the Choice

[pyramid]

Actually, the nebula hud image is not from me but I'll have a look into all sprites and make them DXT5 (that is when I get to reinstalling my gimp-dds plugin).

@loki. Which driver version are you using? (I can't reproduce the errors on my box).

[safemode]

most of the dds files are from me. at the time, there was no problem with them, since the driver didn't take issue with nvcompress's files. Something has changed in the driver to now make it incompatible with nvcompress (including 2.0)' dxt5 files. I dont know what special thing nvcompress is doing that the hardware GL compressor isn't. the nvnews forum doesn't seem to be too up in arms over it, making me think that this is something that affects older gpu's only.

The HUD images that have alpha (and need it) are 1 bit alpha, meaning they should be dxt1a. So those will be fixed.

The only textures that will suffer from the brokeness from nvcompress's dxt5 will be textures that require fine fading in the alpha layer. We'll either have to leave them as png (uncompressed) or compress them via GL through one of the many non-nvcompress programs.

I dont want this to look like we're going out of our way to tailor the graphics to pre-8xxx gen nvidia cards. We're not doing that (mostly). Many of the dxt5 textures are wrongly dxt5 anyway, they thus waste hdd space, video ram, and system ram. This is however, a show stopper, so we'll fix these textures and hopefully not have to do this ever again.

[pyramid]

The HUD images that have alpha (and need it) are 1 bit alpha, meaning they should be dxt1a.

Most of my hud mages have more than 1 bit alpha. I would not recommend DXT1a for HUD images, since DXT1 generates really bad alpha on edges due to 1 bit alpha with dtx1a (tested with gimp-dds plug-in 1.2.1). My recommendation would be at least DXT3.

While the memory need difference between DTX3 and DXT5 is none, and considering that DXT5 creates smoother alpha channel info, I'd still recommend considering DXT5 as standard for VS.

[safemode]

if you got hud images that are translucent, then fine. If the transluscence varies a lot but not distinctly, then dxt5 is the way those should be. If the alpha is the same shade across the image, or only varies in chunks, dxt3 is the way to go. All else goes to dxt1/1a.

Very few images actually use the alpha layer that they have.
Very Very few images actually make use of translucency in the texture.

[safemode]

Well, As of right now, there are exactly 1451 DXT5 textures in data4.x

All of them can't be bugging out or surely we'd notice it in many more places than just planets and wormholes and menu screens. the parts of the llama (besides normal map/bump) are dxt5, and they look fine to me when i'm playing. I'm almost positive it was compressed the same as the rest.


I'm attaching a file that lists every dxt5 texture we have in the game. We need to start a list of verified corrupted textures, so we can see if there is an easy pattern.

[pyramid]

This list seems to be generic list of all dds files (regardless of the used algorithm). E.g.
* ./sprites/planet-snow-hud.png is compressed with DXT3
* ./textures/planets/k_class1.png is compressed with DXT1
* ./cockpits/bomber-cockpit.cpt/shieldf.png is compressed with DXT3 (though it presents artifacts and should be compressed with DXT5)

Not sure though what would be the best way to obtain the list only for DXT5 compressed images in order to narrow the selection to those that potentially cause the problems (due to having been compressed with nvcompress).

[loki1950]

While you guys are debating i found an other



Enjoy the Choice