Flashing/Flicker/Clipping/Graphics Issues, Need guidance.. :/

Hi there, I posted a thread a few months back

/111/9d/314781/1.html

about problems I was having with my 9800gtx+ vid card and flashing/bleeding, etc.

Now I have a geforce gtx 275, 896mb and the same issues are still happening.

Here are some pix and video of what is happening. I'm wondering whether it's the .png transparency issue I've heard about, where the textures can fight with eachother? Even though it seems to be happening with textures that do not appear to have been png files before uploading.

http://picasaweb.google.com/SeraLok/GraphicsIssues#5389575693803445426
(shot at a place called Prestige Prefabs, where almost all textures seem to flash for me)

videos:

http://www.youtube.com/watch?v=2gpx3lFlJZk

http://www.youtube.com/watch?v=bCVJj-lFyHU

http://www.youtube.com/watch?v=JXNYZCWlc80

I've also noticed, after installing a program called Jing, that the Jing UI fights with the SL window. The Jing UI is supposed to stay on top of the SL window, but only part of it stays fully visible, while other parts of it flash and flicker. (haven't figured out quite how to take a video of this yet, since Jing UI doesn't show in the recordings) (fyi SL is the only program that I have that issue with, Jing doesn't fight with browser windows or picasa or anything else)

I have the latest chipset.. I have the latest drivers... I just don't know what to do at this point and I'm even considering switching to a whole new computer... but I don't want to just continue throwing money at this problem. :/


Stats:
Second Life 1.23.4 (12390 Jun 11 2009 15:16:56 (Second Life Release)
Release Notes

Built with MSVC version 1400

CPU: Intel Pentium 4 (Unknown model) (2992 MHz)
Memory: 2047 MB
OS Version: Microsoft Windows XP Service Pack 3 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce GTX 275/PCI/SSE2
Windows Graphics Driver Version: 6.14.0011.9107
OpenGL Version: 3.2.0

libcurl Version: libcurl/7.18.1 OpenSSL/0.9.8j zlib/1.2.3
J2C Decoder Version: KDU
Audio Driver Version: FMOD version 3.740000
LLMozLib Version: [LLMediaImplLLMozLib] - 2.01.27381 (Mozilla GRE version 1.8.1.21_0000000000)
Packets Lost: 11/2518 (0.4%)


Any help or suggestions would be so greatly appreciated.

From your videos, it doesn't look like an alpha sorting issue, which was my first thought, given your description. By all appearances, the objects you're having trouble with were just poorly constructed. You've got thin cubes placed right on top of, and extremely close to, other larger cubes behind them. As you zoom your camera in and out, and move it around, the space between the in-front and in-back surfaces is going to become less than one pixel. When that happens, the larger polygons that make up the in-back surfaces are going to appear to poke right through the smaller polys of the in-front ones. In 3D lingo, it's called Z-fighting.

The solution is to move those in-front surfaces a little further from the in-back ones. The minimum safe distance between any two parallel planes is generally .002 meters. Any less than that, and Z-fighting will be common. And if the build needs to be viewable from far away, then even that number can be problematic. The mimimum could well be as much as .005 or so.


Just so you know the "transparency issue" you heard about has absolutely nothing to do with PNG. I don't know who keeps spreading that misinformation, but it's getting pretty annoying. (Not annoyed at you, since you're just repeating what you heard, but at whoever took it upon themselves to disseminate incorrect info in the first place.) Let me straighten this out for you.

The "transparency issue", as you put it, is commonly referred to as the alpha sorting glitch. When two or more surfaces with 32-bit textures on them overlap in 3D space, the renderer has trouble determining which one to draw as "in front" of the other. So as your camera moves around, they can appear to flip-flop back and forth, or cancel each other out. It's actually very predictable, if you understand how realtime 3D rendering works, but to the casual human observer, it can seem all kinds of bizarre.

If you want to learn more about it, read the transparency guide, stickied at the top of the Texturing Tips forum. For now, just be aware that it happens in just about every single 3D engine in existence, from freebies like SL to video games to professional 3D modeling platforms that cost thousands of dollars. The only reason you don't see it in games is that professional 3D artists are well aware of the issue, so they make a point of designing around it. The reason it's so rampant in SL is simply because 99% of the world is created by amateurs who don't know any better. Most people end up either learning about it the hard way, or else just living with the mystery.

The glitch will occur regardless of file format. (All textures in SL are just a single format anyway, JPEG2000. When you "upload" an image, you're not actually uploading your source file. Your viewer creates a JPEG2000 copy of the image, and it's that copy that gets uploaded.) How PNG relates as a potential contributor is simply that it's easier to end up with a 32-bit texture accidentally from a PNG source image than it is from any other image format that SL supports. It's pretty tough to accidentally add an alpha channel to a TGA, for example. PNG supports multiple forms of transparency, so there's more room for user error. That's it.


As for Jing, any screen capture program can cause a performance hit. Why its interface is having trouble staying on top of the SL window, I'm not sure. FRAPS, a competitor of Jing doesn't seem to have that problem.

thanks for the reply, Chosen. Yes, the png thing was mostly something I heard in passing that I clung to, thinking that could be my problem, because no one seems to be able to explain this, much less solve it.

But take a look at this pic and the 2 after it. In this example, both prims are of relatively same size and thickness.

http://picasaweb.google.com/SeraLok/GraphicsIssues#5389622316366175090

See how there is a .01m distance between them? Quite a gap, yet I still get z-fighting. Doesn't that seem excessive? It's over twice the distance of your high-end estimate. Also, I just think to myself when I go to this prefabs place, the builder of that display could NOT have done that and just left it like that, if it were really just the normal z-fighting, he would have moved them out a slight bit because it would have happened to everybody and they would have notified him...

It's as if somehow, my z threshold or whatever it's called is not right... but how to adjust that??? It seems that the better and faster my vid card gets, the worse this problem becomes. the 9800gtx and now the geforce275 both exhibit this problem, yet my 7900 did not (not to this extent, to be sure, just the normal z-fighting one would expect when things are definitely too close).

re: Jing, it's not a performance hit that is my problem, it's the flicker between jing's UI and SL's window, that actually seems similar to this z-fighting issue...maybe? (also, i have fraps but it won't record my SL pointer, which is what I really need)

Obviously I don't have a lot of technical knowledge on this, I hope my post makes sense, and thanks for your input.

Is Fraps set to capture the cursor? That's in the settings.

It just looks like you are making some textures 32 bit that should be 24 bit.

Targas are teh win for SL.

you're right... either i set it wrong once and thought it didn't work, or there was some other reason i didn't like it.. heh.

That's excellent!

no, these are 24 bit textures... with no alpha channels, so say psp7 (i know, ancient)...

*sighs*

i can only assume it's a driver issue with nvidia that will hopefully get fixed someday... all suggestions about what might be wrong aren't the problem so far.

Can you give a location for the first sign video? I'd go see if it does it to me.