Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: rvo_nl on April 07, 2011, 05:48:19 PM
-
I did ask this one before, but still I cant imagine this is right: every major 3D game I play (Quake 1, Quake 2, Shogo, Heretic) has this really 'grainy' look to it. I know the resolution aint much, but is that really the whole story? Look at the strange pixelated way its rendered, is that how it should look? Is there something I can tweak?
(http://vanooij.nl/FILES/q2ami.jpg)
-
Looks like a dithered 16bit image to me.
-
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.
-
well that sounds mighty plausible (I have no idea how you know all this stuff) 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?
-
Look how much hardware this system relies on that isn't from Commodore/Amiga, but we're still willing to call this an Amiga.
PPC processor, RTG graphics, 256MB of memory, 120GB hard drive.
Might as well be my MorphOS system.
-
Look how much hardware this system relies on that isn't from Commodore/Amiga, but we're still willing to call this an Amiga.
PPC processor, RTG graphics, 256MB of memory, 120GB hard drive.
Might as well be my MorphOS system.
Maybe you should stay on-topic. Especially since your argument is so weak.
-
@iggy
Stay on topic, or get off the thread.
-
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.
-
Is there anything else I could try?
Other than "upgrading" to Voodoo3 or replacing the aging system with something else, not really. As soon as I replaced by A1200 BPPC + BVisionPPC with the peg1 + Radeon I didn't look back. It took me couple of months to realize I didn't even power up the A1200 anymore. I never missed the BVisionPPC... frankly Permedia2 just sucks.
-
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.
-
Maybe you should stay on-topic. Especially since your argument is so weak.
Is it?
What the poster's using barely resembles an Amiga.
Its closer to my Mac.
Other than "upgrading" to Voodoo3 or replacing the aging system with something else, not really. As soon as I replaced by A1200 BPPC + BVisionPPC with the peg1 + Radeon I didn't look back. It took me couple of months to realize I didn't even power up the A1200 anymore. I never missed the BVisionPPC... frankly Permedia2 just sucks.
Piru sums this up pretty clearly. I've got a Voodoo3 I've already retired and am using a Radeon card myself. And my system probably runs Warp3D applications better than a "real" Amiga.
Totally on topic.
When you get to a certain point, replace the system.
-
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.
-
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.
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.
-
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 ;)
-
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.
-
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.
-
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! ;)
-
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.
-
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.
-
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.
-
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..
-
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.
-
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.
-
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
-
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:
+---+ +-+-+
| /| |/|/|
| / | => +-+-+
|/ | (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.
-
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
-
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.
-
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.
-
"r_fullbright 1"
heh :) fun! 2.5fps gain, now finally seeing framerates in the 30's. but yeah it looks like crap..
-
Only 2.5 ? Disappointing. I seem to recall it being a much bigger increase than that.
-
Nope sorry! Perhaps in combination with some other stuff that I already enabled/disabled. I think I have a pretty well-optimised system really. Please see amigaspeed.de.vu, Im well into 604+voodoo3 territory. (I really sound like a '96 quake pc-lamer here)