Warp3D (Bvision) users, please look at this picture

[Karlos]

All I can see is ordered dithering, which is exactly what I would expect from an old 15/16-bit colourdepth minigl based application.

The Permedia2 chip's graphics pipeline uses true colour for every stage until the penultimate one where the "colour" unit converts the pixel to framebuffer format. Your framebuffer is 15 or 16-bits deep and so it applies dithering to diffuse the error caused by the truncation.

The Permedia2 driver has an environment variable that forces dithering to be on for all output less than 24-bit, overriding any application setting. You can turn this behaviour off by setting ENV:Warp3D/Permedia2/Dither to "off".

This will eliminate the perceived graininess from the dithering but will have noticeable colour banding where any subtle truecolour gradients are truncated.

[Karlos]

well that sounds mighty plausible (I have no idea how you know all this stuff)

I have the same hardware and was an early adopter of Warp3D in some of my own coding projects.

but unfortunately it didnt have any effect. I found out theres also the gl_dither 0 setting I can set in the Quake 2 .cfg file, but that also didnt do much. Running the game in 24 bit doesnt work. Is there anything else I could try?

Turn off both the env var and set the gl_dither to 0 together. If that doesn't work then the application is forcing it on, in which case you can't disable it.

Regarding 24-bit mode, some of the old MiniGL applications only use 16-bit regardless of what you ask for.

[Karlos]

frankly Permedia2 just sucks.

It is certainly the weakest 3D graphics chip you can put into an Amiga these days (unless you find an old Cybervision3D) but as a basic RTG card it's fine IMHO.

[Karlos]

Regarding the "off topic" debate. The guy has asked how to deal with an issue on his present system. I'm quite sure that if he wants to upgrade to something faster, he'll still do just that. That still doesn't answer his immediate question though.

[Karlos]

It doesn't have to be faster Karlos. Better would be relatively easy. A Voodoo3 2000 would be a small expense and a big improvement over the Permedia2.

Sure, but unless he plans to put the Voodoo into a different system, then he also has to buy a PCI bridge, which will cost a hell of a lot more than the Voodoo card.

Furthermore, depending on the generation of Voodoo card, he won't be able to get away from dithered 16-bit output either

[Karlos]

Actually, I'm going to have to suggest it is related to dithering still. The Permedia2 cannot do multitexturing in hardware, so when you use non-vertex lighting, the entire scene has to be rendered twice. First, the basic textures are rendered, then (in the case of the permedia) a black shadowmap (as opposed to an RGB lightmap that's used on cards that can do multiplicative blending) is rendered using alpha blending on top. This second pass is also slower than the first since although the shadow map textures are lower resolution, the blending operation requires that each framebuffer pixel is read as well as written back to. Not sure if alpha testing is used to speed that up slightly (it can be used to skip reading the framebuffer pixel when the fragment pixel is wholly opaque, likewise it can skip reading and writing when the fragment is entirely transparent). Anyway I digress...

As the framebuffer is say 16-bits, each rendering pass is dithered and it seems you can't turn it off (judging by your previous attempts). So, in each pass, the the same ordered dithering algorithm is used and the stippling artefacts become even more pronounced. Ideally, the first pass shouldn't have been dithered if a second pass was going to be used, but I don't think it was thought about at the time.

By switching to vertex lighting you achieve a major speed up since you are eliminating that whole second pass.

[Karlos]

Well, for the permedia I could recommend the permedia2 hardware and programmer manuals. I had to sign an NDA to get mine, but I wouldn't be surprised if they are simply on the web somewhere these days

Thanks for clearing that up Karlos. That explains why Vertex lighting was disabled by default: many people are now using Voodoo boards that probably do support hardware multitexturing. I do wonder how the game looks on such a system, compared to mine.

In a word, better. It isn't just that they support multitexturing they also have more blending modes. When you use the non-vertex model on the permedia essentially you are doing this

pass1: framebufferColour = fragmentColour (fragment is texture RGB)
pass2: framebufferColour = fragmentAlpha*fragmentColour + (1-fragmentAlpha)*framebufferColour (fragment is shadowmap ARGB)

For the shadow, the fragmentColour is black, so the first term in pass 2 is 0, not that it really makes any difference to the underlying hardware in this case.

For the voodoo, you can do multiplicative blending. So, instead of simply having a black texture with an alpha channel to dictate how much to "paint" onto the texture, so even without multitexture support you can do something like this:

pass1: framebufferColour = fragmentColour1 (fragment is lightMap RGB)
pass2: framebufferColour = frameBufferColour * fragmentColour2 (fragment is texture RGB)

This allows you to reproduce the same shadowing techniques as the first method (in which case the lightmap RGB is zero) but also to simulate lighting of any colour. If the lightmap was entirely blue, for example, the second pass would result only in the blue component of fragmentColour2 being written into the framebuffer.

Multitexturing doesn't do anything to this other than to allow you to do it all in one pass; a performance optimisation rather than a new way of achieving the result.

[Karlos]

I have actually experimented with a hybrid technique on the Permedia. Unfortunately it was too slow in practise to make any serious use out of.

What I did was to take RGB lightmaps and turn them into monochrome shadow maps. However, rather than totally discarding the RGB data, I extracted it, compensated the brightness for having encoded it into the shadow map and used it to calculate vertex colours for the first pass in a typical 2 pass implementation. If the item being rendered has enough vertices, you can simulate a not-to-shabby looking result.

Unfortunately, it doesn't suit large flat polygons since you can only colour at the vertices. I experimented with tessellating them slightly which improved the appearance, but overall the performance was very poor, even when applying various optimisations to each pass.

[Karlos]

Hello Karlos
>was to take RGB lightmaps and turn them into monochrome shadow maps. However, rather than totally discarding the RGB data, I extracted it, compensated the brightness for having encoded it into the shadow map and used it to calculate vertex colours

Why do you use it as monochrome ?
I mean you can read the lightmap rgba values and use them as vertex colours . no?

I did.

>for the first pass in a typical 2 pass implementation.
2 pass ? What is the second pass if u did the lighting with vertex colours ?

Alain Thellier

I think you misunderstood what I was trying to achieve. Allow me to explain:

It's well understood that the human eye is more concerned with the apparent brightness of something than it is the absolute colour.

Suppose I have a rectangle polygon on screen that is to be shaded with a 16x16 RGB lightmap. If the polygon has only 4 vertices, only the crudest colour information from the light map can be put into the vertices. I could tesselate the polygon a couple of times and increase the the number of vertices to get a better lighting effect but the performance quickly drops as you tesselate due to the extra vertices you have to submit. Suppose we tesselated once, we now have a 9 vertex mesh:

Code: [Select]


+---+      +-+-+
|  /|      |/|/|
| / |  =>  +-+-+
|/  | (x1) |/|/|
+---+      +-+-+


We can choose the colour of those 9 vertices from the RGB map by averaging the neighbouring texels and whilst it's a bit better looking than the original rectangle, the lighting is still way lower resolution than the original lightmap.

You'd have to tessellate to an unrealistic degree to reproduce anything approaching the original intended level of lighting detail.

However, recall that your eye is more concerned about the brightness than it is the overall colour. On that basis, I decided it would be interesting to try and preserve the brightness of the RGB map in it's original level of detail and move the hue/saturation into the vertex colour.

So, I took the RGB map, calculated the brightness of every texel and made that into a shadow map at the same resolution. In the same transformation, I basically "normalized" the brightness of every texel so that only their hue and saturation changed. This was then downsampled and used to calculate the vertex colours for the first pass.

The end results weren't actually too bad. Even without tessellation, the end result looked a hell of a lot better than only using a single-pass vertex colour based approach.

[Karlos]

For quake 1, just enter

"r_fullbright 1"

in the pull down console.

It will generally look pretty awful though as all this does is to skip the shadow map pass. There's no alternative lighting data encoded into the vertices.

Haha.. thanks, I'll have a look. Although Im pretty sure it will be too complex for a beginner. I'm not even half a programmer you know. Took me months to figure out 'simple' raycasting in Flash.

I wasn't entirely serious as they are aimed at driver development. However, the programming manual in particular make interesting reading if you are curious about things like pipelined graphics and rasterisation techniques.

[Karlos]

Only 2.5 ? Disappointing. I seem to recall it being a much bigger increase than that.