Raydium 3D Game Engine

1-.if i maximize the window, i get a segment fault (linux)
It's possible to fix this issue, but I start to think that on-the-fly window resizing is a good idea, since a lot of "advanced" effects are based on window size (there a problem with shadows, too, for example). I'll fix this for now, and see later ...

2-the raydium_hdr_blur is a good candidate to make asm optimizations in a future Smile
ASM is evil ! Portability is good !

3-the downscaling section is made by software. Is better in that way instead of using opengl?
How ? It seems that only a pixel shader program may be able to do this.

4-Can you explain which method are you using to know if the effect should be reseted/activated?
If the "camera" (eye) don't see any HDR texture, its sensibility is set to "max". This sensibility is the alpha factor. So if a HDR texture appears, the HDR effect is at its max, and then I decrement the sensibility using time and the precent of the screen covered with HDR.
All this will be configurable thru a function soon.

5-i have made a new commit with a second pass of the hdr, greater and softer, to make like an ambiental glow. What do you think about?
Nice ! But a bit too .. hmmm white, perhaps. The function I talk about in the previous point will allow user to enable/disable this new layer and its settings (alpa and color).

6-idea. The glow effect could be slightly tinted with the "main" color of the scene.
See above

7-time before applying HDR effect
I didn't play to SOTC, but I know that the game is using a "box" system (indoor, outdoor, ... you're probably read it like me in the making-of), wich does not exist in Raydium (core and arts).
I think our version is more generic, and allows automatically things like :
http://ftp.cqfd-corp.org/raycap2006-04-05-103929-00.jpg
http://ftp.cqfd-corp.org/raycap2006-04-05-104138-01.jpg
... wich needs manual box creation with SOTC, I think.

edit : but the problem now is to find wy this effect is failing (big speed problem) on some hardware !

1-okis

2-jejej, ok ok, not ASM in the future... but a -O3 could be fine during compiling

3-Downscaling:
I have in midn that opengl has a function to do that.
Any way, it can be done in opengl in a more "manual" way: The stencil buffer can be used directly as texture, right? Well, then we create a new buffer of 256x265 and we paint a rectangle with the stencil texture. Then we can copy the buffer to a texture, right?

4-So if i understood well, it have to check ALL the points of the stencil buffer, right?
Using the previuos methos (point 3) we can make a 1x1 texture of the stencilbuffer. That gives us a "medium" value of the texture. If the stencil is quite full of white, the 1x1 texture will be an almost white pixel. After that, we only have to read the values of the pixel.
This method could be combined with a 1x1 reduction of the full colof buffer to get the main color of the scene and apply a dynamic tint to the efect.

5-Ok, i was triyng to reply the effect in shadow of the collosus, and in that game the burning HDR are really burning.

6-:)

7-i think i have didn't explain myself right. I only say that, independently of where you are, if you look at the sun the full efect is not inmediate, it takes a pportion of a second in to be full burning.

i found it:
gluScaleImage
But since it's part of the glu lib i'm not sure if it uses the hardware acceleration.

The problem is not to scale, but to blur
(gluScaleImage() works on client memory (RAM, here), so it's probably a 100% software function)

To get current "exposure", I only check my resized texture (64x64), not the whole "fullscreen" stencil. I think you're searching in the right direction (doing all this thing in hardware), but I'm not sure that it's possible without shaders ... :/

i have seen the new commit.
There is a demo to see the new features?

No, not yet. The idea here is to allow user to change simple HDR settings. For some other tests, I'm currently using something like this, for a "sunset-like" rendering :