16 bits ZBuffer + native aniso?

[Karlos]

Once some of the newly reported bugs are ironed out, I will look into updating the API. I don't want to do too much there because Warp3D is basically deprecated.

Things like aniso are considered as OpenGL "Extensions". Maybe it should be faster for you to create something like SetEXTParams() and have 32 new flags. (?) Simple idea.

Maybe, but if I was going to overhaul the state mechanism, I'd probably do it with some sort of taglist style approach to allow multiple states to be set per call. More than likely, a state stack, so that changes can be locally pushed, then forgotten.

I know W3D is deprecated. But I like it because we actually have it, and it does it's job quite fast. You'll be surprised to see how complex rendering we can achieve with Warp3D when called from a fast engine.

Actually, I'd probably be one of the few people that wouldn't be surprised

Thanks, I'll take care about this.

EDIT: BTW, with the latest version, I experience some texture corruption, specially with higher resolution. With my own engine, or with some games. Unfortunately I can't give you a special way to reproduce it. Sometime it works, sometime it doesn't. With my engine, at 1920x1080, the textures looks 95% of time corrupted. Looks like it only affect the biggest mipmap level, not the smaller ones. If this can help...

Is it a duplicate of this

http://forum.hyperion-entertainment.biz ... =14&t=1480

?

[Crisot]

Hummm... Not really.

http://crisot.free.fr/souc/amiga/w3d_corrupt.jpg

-I was wrong, all mipmaps are affected.
-The corrupted textels are "blinking" (Changing color on every frames, but corrupted textels are allways the same).
-When switching back to Workbench to launch SGrab, I noticed pixels corruption on my Workbench, quite the same corruption than on textures.
-I had 50 MB of free vram.

[Karlos]

Hummm... Not really.

http://crisot.free.fr/souc/amiga/w3d_corrupt.jpg

-I was wrong, all mipmaps are affected.
-The corrupted textels are "blinking" (Changing color on every frames, but corrupted textels are allways the same).
-When switching back to Workbench to launch SGrab, I noticed pixels corruption on my Workbench, quite the same corruption than on textures.
-I had 50 MB of free vram.

It looks like an overrun bug*. Can you confirm whether rolling back the W3D_Picasso96.library to the previous version fixes it? Make sure you reboot before re-testing.

*In the R100 and R200 machines, the original texture and all mip maps are stored in a single monolithic allocation within the video memory and the filtering engine performs the necessary address calculation into the set. If there are any alignment bugs when uploading different levels, the start or end of a previous level might get corrupted.

[Karlos]

@Crisot

I've re-read the radeon DDI regarding texture filtering and compared it to several GL implementations.

For minification purposes, Radeon define the following filter types

Nearest
Linear
Nearest mipmap Nearest
Nearest mipmap Linear
Linear mipmap Nearest
Linear mipmap Linear
Anisotropy Nearest
Anisotropy Linear
Anisotropy Nearest mipmap Nearest
Anisotropy Nearest mipmap Linear

You will notice that there is no "Anisotropy Linear mipmap X" options. Anisotropic filtering is basically an alternative to conventional "trilinear" (Linear mipmap Linear).

If you take a look at a typical Mesa driver:
ftp://ftp.uni-hannover.de/pub/mirror/bs ... deon_tex.c

you will see that these are mapped to the GL filter enumerations when anisotropy is enabled, as follows:

Code: Select all

switch ( minf ) {
   case GL_NEAREST:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_NEAREST;
      break;
   case GL_LINEAR:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_LINEAR;
      break;
   case GL_NEAREST_MIPMAP_NEAREST:
   case GL_LINEAR_MIPMAP_NEAREST:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_NEAREST_MIP_NEAREST;
      break;
   case GL_NEAREST_MIPMAP_LINEAR:
   case GL_LINEAR_MIPMAP_LINEAR:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_NEAREST_MIP_LINEAR;
     break;
}

That is to say, when anisotropic filtering is enabled, the GL_LINEAR_MIPMAP_X and GL_NEAREST_MIPMAP_X enumerations are treated the same way. I had a slight transposition bug in the filter logic for the radeon driver. I've now corrected this. Hopefully, it will produce the expected results.

[Crisot]

It looks like an overrun bug*. Can you confirm whether rolling back the W3D_Picasso96.library to the previous version fixes it? Make sure you reboot before re-testing.

Yes, reverting this only library did the trick. No more corruption, even at very high resolution, with 2 instances of the game running and many windows. Cool.

I've re-read the radeon DDI regarding texture filtering and compared it to several GL implementations.

For minification purposes, Radeon define the following filter types

Nearest
Linear
Nearest mipmap Nearest
Nearest mipmap Linear
Linear mipmap Nearest
Linear mipmap Linear
Anisotropy Nearest
Anisotropy Linear
Anisotropy Nearest mipmap Nearest
Anisotropy Nearest mipmap Linear

You will notice that there is no "Anisotropy Linear mipmap X" options. Anisotropic filtering is basically an alternative to conventional "trilinear" (Linear mipmap Linear).

If you take a look at a typical Mesa driver:
ftp://ftp.uni-hannover.de/pub/mirror/bs ... deon_tex.c

you will see that these are mapped to the GL filter enumerations when anisotropy is enabled, as follows:

Code: Select all

switch ( minf ) {
   case GL_NEAREST:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_NEAREST;
      break;
   case GL_LINEAR:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_LINEAR;
      break;
   case GL_NEAREST_MIPMAP_NEAREST:
   case GL_LINEAR_MIPMAP_NEAREST:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_NEAREST_MIP_NEAREST;
      break;
   case GL_NEAREST_MIPMAP_LINEAR:
   case GL_LINEAR_MIPMAP_LINEAR:
      t->pp_txfilter |= RADEON_MIN_FILTER_ANISO_NEAREST_MIP_LINEAR;
     break;
}

That is to say, when anisotropic filtering is enabled, the GL_LINEAR_MIPMAP_X and GL_NEAREST_MIPMAP_X enumerations are treated the same way. I had a slight transposition bug in the filter logic for the radeon driver. I've now corrected this. Hopefully, it will produce the expected results.

Ok, interresting. So there is no way to have interpolation between the different mipmap levels when anisotropic is enabled.

I've read somewhere peoples suggesting to use anisotropic_linear with no mipmap, to avoid the hard transitions problem. I'll try tomorrow, and see if it doesn't look too sharp, and also not destroy the bandwidth too much...

Thanks for your search.

[Karlos]

Yes, reverting this only library did the trick. No more corruption, even at very high resolution, with 2 instances of the game running and many windows. Cool.

I was able to reproduce the bug in the end and so I should be able to fix it. I'd rather not lose the "reduced wastage" features it has because they are useful on permedia

Regarding the corruption itself, it actually only happens on textures above a certain size (512x512 or higher it seems). You will see it at every mip level if you use auto mip mapping because the corrupted texels in the largest version will be resampled too.

I already have a feeling I know where the problem is and if possible will try to fix it tonight.

Ok, interresting. So there is no way to have interpolation between the different mipmap levels when anisotropic is enabled.

I've read somewhere peoples suggesting to use anisotropic_linear with no mipmap, to avoid the hard transitions problem. I'll try tomorrow, and see if it doesn't look too sharp, and also not destroy the bandwidth too much...

Thanks for your search.

Be aware that the actual minification filter mapping was slightly wrong with anisotropic enabled. When the Radeon and R200 drivers are next updated, expect the following behaviour for MinFilter when using anisotropically filtered textures:

W3D_NEAREST -> RADEON_MIN_FILTER_ANISO_NEAREST

W3D_LINEAR -> RADEON_MIN_FILTER_ANISO_LINEAR

W3D_NEAREST_MIP_NEAREST,
W3D_LINEAR_MIP_NEAREST -> RADEON_MIN_FILTER_ANISO_NEAREST_MIP_NEAREST

W3D_NEAREST_MIP_LINEAR,
W3D_LINEAR_MIP_LINEAR -> RADEON_MIN_FILTER_ANISO_NEAREST_MIP_LINEAR

[Crisot]

W3D_NEAREST -> RADEON_MIN_FILTER_ANISO_NEAREST

W3D_LINEAR -> RADEON_MIN_FILTER_ANISO_LINEAR

Aaah! Seen the problem Not a big deal, I'll do with it. A couple of days ago, I was living without this anyway.

[Karlos]

Aaah! Seen the problem Not a big deal, I'll do with it. A couple of days ago, I was living without this anyway.

FYI, some proposed changes to the Warp3D API have been ratified. I had a setback this week but developer control over the Z buffer width and per-texture anisotropic filtering will be added soon.

The proposed solution is that the existing hint mechanism will be used to indicate to the driver that you want a "fast" as opposed to average or nice Z buffer. For the R100 and R200 drivers, at least, this will imply a 16-bit format. Other drivers can and will ignore this hint as appropriate.

For anisotropic filtering, the enumeration used for minification filtering will be extended as outlined earlier. Thus, to enable this filtering, you will continue to use the IWarp3D->W3D_SetFilter() call to enable it. To control the degree of anisotropy, the proposed solution is to add a new method, which will look something like this:

uint32 IWarp3D->SetMaxAnisotropyLevel(W3D_Context*, W3D_Texture*, uint32 level);

The level parameter will be an enumeration. Selecting an anisotropy of 1 to 1 will in effect, disable anisotropic filtering, regardless of whether or not it was asked for in W3D_SetFilter()

[AmiDARK]

Hi Karlos,

If your idea to add this new method with :
uint32 IWarp3D->SetAnisotropyLevel(W3D_Context*, W3D_Texture*, uint32 level);
is approved and added, we should be able to add this to MiniGL then.

Kindest Regards,
AmiDARK

[Crisot]

This is really a great news. The solutions are really smart, mostly based on existing functions. Great work!