Warp3D (Bvision) users, please look at this picture

[rvo_nl]

Listen, I appreciate your concerns. I know the Voodoo is faster. But it wasnt built by an Amiga company and for me that is what counts. I dont have PCI anyway. Too much hassle. I wanted to built the ultimate classic Amiga and thats what I have. Ofcourse you may think different, but please, in another thread

@Karlos, thanks for your answer. Will fiddle around with those settings again using a different game.

[Iggy]

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

Absolutely true. Heck, I could give him the Voodoo card, but it is limited to 16bit color (with more memory and better 2D and 3D performance though). And the PCI backplane would be costly.
I'm rather surprised that with all the other investments, he hasn't added that.

[Piru]

it wasnt built by an Amiga company and for me that is what counts.

I can name several components from your system that weren't built by an Amiga company. Oh the sacrilege!

[rvo_nl]

I know, and I expected your answer But I think you get my general idea. If I was going to use this machine as my main computer, I wouldnt have bothered with a Bvision. Or even 68k.

[rvo_nl]

A small update here. It turned out to be something quite different. The fact Quake2 looked this way had to do with the configuration of the game, aswell as the low resolution. Now that I enabled Dynamic/Vertex lighting things are looking a LOT better. The game also runs much faster, up to 33fps in 640x480 (quite an achievement, Q1 does max 16fps in that screenmode). Its just about fast enough to play in 800x600, which basically removes the dithered visuals.

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

[rvo_nl]

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.
 
Again, I find this really fascinating, is there some website or books you can recommend? Would love to learn more about this subject. Just the basics will do, mind..

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

[woof]

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?
This way you will do color-lighting and not only grey shade

>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

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

[jj]

Slighly OT but there is a really good article in this months edge about 3D well worth a squint.
 
I love EDGE really good articles about the games industry etc
 
Not this sort of 3D though it does relate, more about how stereoscopic 3D is pretty shabby

[rvo_nl]

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

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.
 
Anyway, thanks for all the help and inspiration. Im happy Q2 now runs at decent pace in 800x600. The only thing that bothers me is the low framerate in Quake 1 (using GLQuakeWOS). Was looking around to see if Q1 had a similar flag I could set to force Vertex Lighting. But then my framerates are not that different when I compare them on amigaspeed.de.vu. I guess the Frieden brothers just know Warp3D a lot better. And well, they got paid for it
 
Funny to see Peter Gordon in the credits too. I remember him from the IRC days.

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

[rvo_nl]

"r_fullbright 1"

heh fun! 2.5fps gain, now finally seeing framerates in the 30's. but yeah it looks like crap..

[Karlos]

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