Messing with LOD bias... and a question about AA and consume

Rev-
I'll look forward to seeing it. Like I said, you have your work cut out for you. Trying to appropriately express texture aliasing on a website is like trying to give directions to someone who only speaks Japanese and you're speaking German. :)

jackkoho-
I use 10x7x32 as well, and 4xQ works well for texture aliasing- not so hot for edge antialiasing in the latest drivers in OGL (very nice for D3D though).

I don't know what OS you're running, but at least on the Win98se drivers LOD Bias is locked at full. Add anisotropy and it's a bit overly aggressive. For this reason, be *sure* to go into advanced rendering options, turn off the texture filter and adjust the texture sharpness to the border between (Blur) and (Sharpen).. I usually run mine on the first notch after (Blur).

If this still doesn't do it for your monitor, Performance AA is also very underrated for OGL with current drivers (9021's in my case). As the Quality SV in the latest betas leaves a bit to be desired compared to previous drivers, Performance mode picks up edge AA quite nicely.

In either case, it's not a lot of work to get very clean IQ with nice texturing and detail. I'm still tweaking my GF3 to get rid of the crawl/shimmer on stairs as the texture choice for this game was a little surreal (almost to the point of Jedi-2 floors, but we wont go there right now). I keep flipping between the 28.32's and 27.70s and losing hair. :)
 
Doomtrooper
thanks for the shots.

Rev.
I don't know what the target audience is for your article, but here are some basic questions you might like to answer:

What is LOD bias? I assumed it was something to do with the amount of geometry being used (e.g. a model in the foreground using more polygons than the same model in the background), but from reading the replies here it seems it has more to do with texturing. How is that different from using mip-maps?

Why does adjusting the LOD bias cause/effect texture crawling?

Why is LOD bias adjustable? If I were a developer I would just say here is my product, like it or lump it. Maybe it doesn't cost anything for the developer to allow it to be adjustable. I'm sure like me 99% of users wouldn't know what they were doing with it anyway!

Just some thoughts.
 
Roger-
What is LOD bias? I assumed it was something to do with the amount of geometry being used (e.g. a model in the foreground using more polygons than the same model in the background), but from reading the replies here it seems it has more to do with texturing.

You are correct. :) LOD = Level of Detail- be it textures or models, it defines methods of using varying levels of details FOR textures and/or models.

In general, it is equally self defeating to try and render a 6000 polygon model that is far, far in the distance as it is to try and squeeze a 512x512 texture into a far, far in the distance box of 4x4 pixels, so varying levels of detailed TEXTURES and MODELS are employed. A game might have 10 to 12 varying levels of detail textures (or mipmapped as such) as well as 10, 100, 200, 600 and 1000 poly versions of models and these are flipped between as the Z coordinate increases.

It's very easy to confuse "LOD Bias" between the two and they are usually not related as one simply manually flips between different detail levels of models (or adds/removes models totally) and the other adjusts at what detail level textures are mipmapped from.

So in theory, and in a simplistic, perfect universe, by adjusting LOD BIAS, you are simply changing the threshhold of Z where this transition between detail level occurs... and you can do this for geoemetry LOD and texture LOD. You might think of the maximum aggresive texture LOD bias would force the 512x512 textures to be used for all detail levels, and the maximum aggressive geometry LOD Bias to use the 6000 polygon models for all distances of Z as well. And the reverse would use the lowest detail models and textures for the full display. The best performance as well as the 'cleaner' output would lie somewhere in between.

This is a perfect world/utopian example and not entirely accurate for all implementations.

So for the purposes of what we are discussing here, we mean specifically texturing LOD Bias and not geometry. Geometry LOD is clearly visible in screenshots and can be illustrated easily. Texture LOD (and associated 'noise' in motion from added aliasing) is very difficult to see in screenshots- hence the issue. :)
 
The difference between geometry and texture LOD is that with geometry on the whole its mostly still used to make rendering easier, not to prevent aliasing (it will become a problem in the future though, when what was once drawn into a texture becomes explicit geometry and pixel sized polygons become the norm).
 
mipmap selection

tobbe said:
Doesnt that make either nv or atis OpenGL a non-conformant implementation, since afaik mipmap selection is unambigously defined?

Not necessarily. First, the spec allows you to approximate the the D-level calculation. Secondly, because of these allowed approximations, that allows a whole range of possible conformant results.

Read the OpenGL specs at www.opengl.org.

Anyhow, if the vendor allowed you to tweak the LOD however you wanted, who cares if you tweak it out of spec? The idea is to give the user the image quality or performance that they prefer. I know for a fact I will be adding such a tweak for my own use... 8)
 
Noko-
Your scaled example doesn't even need more than a still/single frame... and is not symptomatic of the types of comparisons being created.

Sharkfood,

Yes you are correct, that was an example only plus note it was a 256color gif which could in itself cause aliasing. Anyways showing texture aliasing using two or maybe three frames I believe would be easy. I've shown servere texture aliasing at Beyond3d.com in the past on my Radeon using two images. All you had to do was flip between the two manually with your browser.
 
I have completed my article. It is on the server and is waiting for Wavey to launch/announce it so keep checking our front page (just click the B3D image at the top right of this page :)) for the link when he announces it. Last page (which is the 2nd page!) includes a link to this thread.
 
OT: I usually tend to ignore any "commercials"/flashing banners or the like, but that new purple flashing banners on the left hand side of the front page really poked my eyes ack. (I guess I made Simon happy again today ;) ).
 
could someone with a GeForce card please post three screenies for me (crop a viable part, compress and e-mail to undac@hotmail.com and I'll host them if you can't)
1st: defualt LOD
2nd: -3 LOD
3d: -15 LOD

I'm really curious about -15

anyways, damn ATI for not supplying a LOD tweak key for D3D!
 
I liked the article and the java proggy does show it fairly nicely.

My only commentary on the article is there are a couple spots that I believe are a little misleading:
If my observations are anything to go by, it appears that reducing texture aliasing as an artifact caused by aggressive LOD Biases would be best addressed by ever higher levels of anisotropic filtering rather than ever higher levels of multi-sample anti-aliasing as per NVIDIA's GeForce4 Ti4600 (which does reduces aliasing but to a very slight degree).

as well as:

Note that this artifact is very slightly cured by using 4x Multi-Sampling Anti-Aliasing on the GeForce4 Ti4600 (since this will anti-alias the edges of the gratings) but it is cured to a higher degree with 8x anisotropic filtering.

Unless you are specifically referencing Quincunx, 4xS or (other) post-filtered/blend addition methods of GF3/4 MS/HRAA, in the context of "texture aliasing", multisampling cannot provide *any* level of improvement whatsoever as there is no texture re-read between samples.

It's true grating edges or the like can be improved through multisampling, but this is not texture antialiasing- it's simply providing a slight form of edge AA at the primitive borders that contain the textures. So thus textures are still left untouched and not antialiased.

Perhaps the example given with JK2 (excellent choice, by the way- I've spent massive hours dealing with the God forsaken floors in this game) isn't the best as there are plenty of single texure/non-alpha blend examples of patterned floor textures without primitive edges to show the lack of texture antialiasings associated with multisampling. I just feel it's not entirely accurate to offer multisampling as having any form of solution (regardless of how slighted or underemphasized) when there is no provision in the method... unless also adding a post-filter/blend or neighbor-sampling method on top of it.

Lastly, one bit I found interesting-
However, it is also likely that super-sample anti-aliasing would reduce texture aliasing but with super-sampling involving even higher fillrate and bandwidth demands, performance may suffer too much to make any image quality improvements matter at all.

The only real reason for this is this rather uninspired outlook on it's effect on texture aliasing. Anyone that has used a GF Ultra/Pro, 8500 or V5 knows the effects of SSAA on texture aliasing is profound- much more profound and in deserving of much higher praise than this slight reference and quick shoot down due to impending (and I'd also offer illusionary) hardware limitations.

I remember reading a John Carmack .plan like a year ago or more concerning 64 bit color (if anyone has it handy, it would be very interesting to re-read now that we are near to where it projects). Interestingly enough, his basis for the insertion of 64 bit color into the nearby future was accomodated by assuming a Moore's law progression in memory bandwidth and fillrate. He referenced people's qualms for AA versus 64 bit and also assumed 4x or higher supersampling would have bandwidth and fillrate to spare so there would be adequate ceiling to implement 64 bit color support as well.

I think the more supersampling is "tossed in the back of the book" and/or downplayed from HRAA misconceptions and support (and infused with anisotropy as an acceptable cure-all), the more likely we'll see focus on "memory crossbar" and other *fractional* improvements, versus either scalable, EDRAM or other larger improvements. I do not reference Rev's article as being the participant here- but instead the overall mentality abroad.

The demand has to be there before the goal is etched in stone. I quite frankly think the average gamer has given too much slack to HRAA/Multisampling + degrees of anisotropy when SSAA/jittered handles the whole picture nicely from a complete view, and is an absolute godsend when coupled with anisotropy.

The 8500 is pretty darn close to that goal- or at least halfway there when put into perspective with JC's utopian projected world today. I also know with crossbar and chip efficiency, the GF3/4 are also almost there in terms of offering a realistic SSAA solution given their effective bandwidth. It seems we are at the borderline, but just a tad too late... and with perception slipping away from the "Real McCoy" and in favor of the "lesser substitute + commentary to pacify." :)
 
Ante P said:
anyways, damn ATI for not supplying a LOD tweak key for D3D!

There is a registry key called TextureLOD for D3D. I saw no difference though when I tested it, maybe someone else have better luck.
 
Humus said:
Ante P said:
anyways, damn ATI for not supplying a LOD tweak key for D3D!

There is a registry key called TextureLOD for D3D. I saw no difference though when I tested it, maybe someone else have better luck.

hmm where did you find that one?
I couldn't find anything like that in the current drivers(?)

anyways I'll toy with it and report back here right now :)
 
Heck, I haven't been able to get the OGL LODBias to do anything at all either. From values of 0 to 6 and 0 to 8, there is no difference in IQ or performance, at least in the Win9x/ME drivers. It's effectively ignored, changed or otherwise broken and has been for a loooong time.
 
Ante P said:
Humus said:
Ante P said:
anyways, damn ATI for not supplying a LOD tweak key for D3D!

There is a registry key called TextureLOD for D3D. I saw no difference though when I tested it, maybe someone else have better luck.

hmm where did you find that one?
I couldn't find anything like that in the current drivers(?)

anyways I'll toy with it and report back here right now :)

You'll find it by logging the registry read and writes with RegMon. Just rechecked now, and it's definitely there in the 6052 driver at least.
 
A nice clear article. I for one am much the wiser.

I see in the list of articles there is one called 'Anisotropic Filtering Explained' and another called 'Super-sampling Anti-Aliasing Analysed' which I don't seem to be able to get at. Any chance of recovering those?
 
Humus said:
You'll find it by logging the registry read and writes with RegMon. Just rechecked now, and it's definitely there in the 6052 driver at least.

you mean the driver puts it in the registry?

I tried playing around with the LOD through the .ini of the Kreed Tech Demo but that didn't even change anything either. :-?
 
No, but whenever you start a game the driver will read in all those registry keys supported, most will probably not be found in the registry on the average system and will then get a default value. RegMon just sits in the background logging all registry activity and is a very handy tool for checking what tweaks are available. It only gives you the names though, not possible values and type.
So, when you log with RegMon you'll see that the driver tries to read a TextureLOD key (among a lot of other keys). But either the values I've tried are invalid or it's just broken. There was a new dev driver posted today, I'll recheck with them tomorrow, feel to sleepy right now. (Saw a nice performance boost btw :))
 
Good job Reverend, I enjoyed your article and your java applet worked great in showing texture aliasing. Now only if you had a Radeon8500 series card to show the differences between the two technologies of ATI and Nvidia in rendering textures.
 
Now only if you had a Radeon8500 series card to show the differences between the two technologies of ATI and Nvidia in rendering textures.

I dont think the forums could handle the crossfire-flurry of posts concerning such an article. :)
 
Back
Top