Hybrid Rendering

[vi-wer]

Sorry, I probably linked it to the wrong lib, I'll correct it next time. If you need the DLL you can get it from http://www.zlib.net/.

I was able to test the demo with an ATI X1300 and it didn't work (but what's good about it, it didn't crash but gave me warning which I forgot to add first time). It's probably senseless to test it for now. None of the ATI cards/drivers seem to support the OGL extension needed for this. I was trying to add an alternative rendering method but I have troubles to use it with irrlicht. If I succeed I'll upload a new version.

"Alone In The Dark"

Isn't it the first game that used prerendered backgrounds (although they look more like drawn)? At least I don't know any other that has been made before this one. I even have this game somwhere on a disc (1+4).

[sio2]

It's probably senseless to test it for now. None of the ATI cards/drivers seem to support the OGL extension needed for this.

Did I see that you're using native GL calls? Isn't there a way of doing the compositing with Irrlicht?

[vi-wer]

Right, I'm using some OpenGL extensions. The only way I can think of doing this with irrlicht is drawing a lot of vertices using drawVertexPrimitives. And for a resolution of 800x600 there are plently of then. I've tried it and had 30fps only. Besides it's not possible to draw more than 65535 vertices at once.

[sio2]

Right, I'm using some OpenGL extensions. The only way I can think of doing this with irrlicht is drawing a lot of vertices using drawVertexPrimitives. And for a resolution of 800x600 there are plently of then. I've tried it and had 30fps only. Besides it's not possible to draw more than 65535 vertices at once.

I noticed from another post that you're drawing 800x600 GL_POINTS. Is this to fill depth values? Wouldn't it be better to use a screen-aligned quad, a texture with your depth values and a fragment shader?

[sio2]

Hang on - why are you writing depth values at all? Haven't you got geometry that defines the static world? Just draw that to init the depth buffer and use the pre-rendered background as a screen-aligned texture; then render your dynamic stuff with depth-buffering.

[vi-wer]

Wouldn't it be better to use a screen-aligned quad, a texture with your depth values and a fragment shader?

Shaders are exactly what I was trying to avoid. Even though them are probably faster and easier to implement. But if I don't find another way I probably will use them.

Haven't you got geometry that defines the static world? Just draw that to init the depth buffer and use the pre-rendered background as a screen-aligned texture;

That's what I thought about at first. For some scenes it might work but for something like the second room in the demo it won't do. I'm using particles to create that grass-like things. And it's impossible to convert them to polygons or even draw them with irrlicht (there are >5000 of them). You see, that "writing depth values" method is still the better choice. I just have to find a way to make it faster and working with most of the gfx cards.

[sio2]

Shaders are exactly what I was trying to avoid. Even though them are probably faster and easier to implement. But if I don't find another way I probably will use them.

I'm interested in this myself. I can write the core Irrlicht framework for you if you like. I already have the media from your demos so I can use that for building a test app. If could PM me with the format of the depth buffer (it doesn't appear to be 800x600 as I'd expect).

I used to write OpenGL drivers, and seeing half a million GL_POINTS makes me feel ill. The driver is batching them for you, but you still have the overhead of half a million glVertex* calls each frame.

That's what I thought about at first. For some scenes it might work but for something like the second room in the demo it won't do. I'm using particles to create that grass-like things. And it's impossible to convert them to polygons or even draw them with irrlicht (there are >5000 of them). You see, that "writing depth values" method is still the better choice.

Fair point. You do want a "pre-rendered" depth buffer in those type of cases.

[agi_shi]

~700FPS with shadows on, ~1300FPS with shadows on and sydney invisible, ranging from 1700FPS to 2500FPS with shadows off. Then in a few seconds the FPS meter goes to 1FPS, even though I'm still getting extremely high updating (according to FRAPS, which is limited to 999FPS due to my old version).

[vi-wer]

Back again with a new demo release which you can get here.

Summary:
- it uses shaders now but does not seem to be faster
- added new room, re-rendered the scene
- selection dialog on startup
- DirectX and OpenGL
- widescreen friendly

[BlindSide]

The DX version should hopefully run on the older ATI cards now, particularly the Radeon 9000. This is if you stuck to shader model 1.4 though.

[christianclavet]

Here is my hardware/system:

Windows XP SP2, 2Go ram
GeForce 7600GS
AMD Athlon XP 2800 (2.0 Ghz)

Here is the result:
Around 675 FPS without shadows
Around 230 FPS with shadows

[sio2]

Back again with a new demo release which you can get here.

Summary:
- it uses shaders now but does not seem to be faster
- added new room, re-rendered the scene
- selection dialog on startup
- DirectX and OpenGL
- widescreen friendly

Looks great! With shadows I get 490/590fps (GL/DX) and 1570/2110fps (GL/DX) without shadows.

I'm glad you were able to get the GL/DX shader stuff I sent you working with your app. Note that although it may not seem faster you should be using less cpu with this method and hence have more cpu for your game stuff - the bottleneck may still be GPU, but you should now have more CPU.

The shader method I sent you writes to DEPTH in the pixel/fragment shader and hence disables hierarchical Z. Your method utilises hiZ but negates its usefulness by rendering to each pixel individually. Of course, you are free to use whichever method you like in your app. The shader-based method may yield better results as you add more cpu-intensive work into your game.

[omaremad]

I have a idea for a fixed function hw accelerated solution:

Ok this is about comparing a depth from a prerendered image with deph of 3d models, whoever is closest to the camera is the one that ends up being shown.

A very fast test in fixed function hw is the alpha test (not apha blending), alpha test can compare the alpha values of two fragments, the exsisting one and the incoming one, then either keep the old one or replace it with the new one depending on the result of the test.

Its easy to get the prerendered depth into the test, just add the depth of the prerendered scene in its alpha component (use some format like tga).

RGB = colours A = depth

No the harder bit is getting the depth of meshes on a fixed function system without doing any RTT or using shaders.

Now we use the under utilised texgens,
GL_OBJECT_LINEAR: takes vertex pos and makes the s texturecoord (x in other words) equal to the distance from a predefined plane. The predefined plane could be the camera, that means coord s will be depth.

Now we need to convert texcoord s to a alpha value so it enters the test, this can be done via a texture with increasing alpha value from left to right.

The alpha test compares and the sorting does its job, early z out is preserved and cpu is idle.

I wanted to do it in fixed function since back when these games were being made they didnt have the shaders / cpus to do this thing, but apparently they just used several layers of prerendered backgrounds.

Initing' the depth buffer with a low poly model is prolly the most practical since you need a low poly model for collision data too, but the method i listed above can take per pixel depth (a hybrid of low poly collision tests and my depth/alpha test will provide good speed and quality).

[vi-wer]

At first some facts to the last release:
- OpenGL driver requires pixel shader 1.1
- DirectX needs pixel shader 2.0 (the last DX SDK (June) I have does not allow me to use lower versions)
- the depth is saved as 16Bit grayscale PNG file (great compression, also used for animated depth/alpha in MPEG's .mza channel)
- depth texture is passed as A1R5G5B5 texture to the shader
- every room has a different setting:
-- 1. room has two layers and two lights
-- 2. room has one layer and two lights
-- 3. (new) room has one layer and one light
The more layers the slower it becomes. If shadows are enabled it needs more time to calculate them when more lights are enabled.
Conclusion: the highest framerate can be reached in the 3rd room. So if you post the FPS please refer to the first room

There seems to be something wrong with the OpenGL driver/shader. Have you noticed a difference between DX an OGL driver? For me, I can't see the transparent sculpture when using OpenGL driver, though it does work fine with DX.

The shaders are currently not optmized. I tried to write precalculated depth values directly to the texture, but I had some wrong results with OpenGL (have't tried it with DX yet). So what I'm doing is calculating them within the shader which results in a framedrop of 200fps on my configuration compared to writing precalculated values. But I can reduce the 7 operations to 3 which should gain some more fps.

@sio2: your app did not worked properly for me but it was helpful. I could use some parts as base. Thanx.

@omaremad: I don't really understand how to do this with the alpha test but using the alpha channel for depth is a bad idea (although it might work). As you see I'm using 16Bit values for depth but irrlicht only provides textures with 8Bit alpha, which is not enough for a nice look. Besides I need the alpha channel. And initiating the depth buffer with a low poly model won't work. Take a look into the 2nd room. Also it's additional work to create these models. I'm using simple boxes for collision detection.

If someone's interested: I uploaded the new backgrounds to my site, the link is in my first post.

[omaremad]

I recommended alpha test since i think its the fastest compare on the gpu.

Btw a drop of 200 fps isnt bad at all, it depends from where it happened, the siginicficance of the results you get from a frame rate timer decrease as the frame rate goes up. Also drop in frame rate is not linear to the extra processing time.


(table shows drops of 50 fps steps)
If i was you id say this is fast enough. Welldone.