HDR Demo

WIP games, tools & toy projects Archived Projects
#1

Hey guys,

I’ve just finished putting together a tech demo in the 3d engine I am working on, it’s more to iron out some little bugs in the engine then to show off a fully featured demo, but that’s not to say that it can’t look pretty is it?

The demo was written in lwjgl and makes use of some pretty advanced OpenGL features, it uses a light based forward shading method and accumulates the effect of each light on the scene into an offscreen float texture. The next part of the render takes the float texture and ‘copies’ any values from the image which are >1 into a 512x512 buffer. This buffer is then Gaussian blurred along the x axis, then y axis (This method is discussed in the GPU Gems book) 3 times so that a nice smooth blur exists on the texture. This is then overlayed on the original image to create the HDR portions of the final scene.

The demo requires the following:
OpenGL 2.0 Support
GL_ARB_TEXTURE_FLOAT

And it is recommended that GL_ARB_TEXTURE_RECTANGLE is also present, but is not needed (The fallback path to normal power of 2 textures has not been extensively tested)

http://strumpy.org/Games/Webstart/deploy.jnlp
w,a,s,d to walk around
mouse to look
h to toggle HDR

Known issues:
There is some form of depth buffer corruption occurring on mac osx, if anyone sees this and has suggestions feel free to offer them, I would appreciate it greatly.
The keyboard input is not being debounced at the moment, this means it make take a few hits of the ‘h’ key for the toggle to actually work.

If the demo crashes in flames or errors out in a bad way please post the log so I can fix the issue. The log is called “gameenginelog.txt” and will be created in the deploy path for your webstart. The log is also printed to the console, so you can also cut and paste from there.

Enjoy

#2

Looks good, very shiny. :o

However you don’t seem to have got much coverage with the bloom - what method are you using to perform the blur?

#3

I’m doing a horizontal pass, saving that to a texture, then doing a vertical pass on that.

You are correct, it doesn’t get too much coverage, and I was trying to fix that up a tad yesterday. I may rewrite my shader, as at present if I turn the radius up it gets quite streaky and the only way to fix that is to do more passes with the blur, and they eats GPU time (see the attached image for a look at just the HDR portion if I try to increase the radius).

The HDR portion of the image is true HDR, it’s the left over from the original forward shading of the scene. I may end up removing this though so that it works on cards without floating point textures, or at least write a render path for those cards.

I hope I addressed your question, if you want more details or have some advice about the blur I am doing I would love to hear it.

This is what happens if I push the blur radius too large:

http://strumpy.org/Games/blurpic.png

#4

Very nice demo. I love those little techy demos, they make my day ;D

How are you extracting your highlights? Are you filtering the >1.0 values that come from the lighting equations to another texture, bluring that and applying it on the scene?

Another thing, you could try using a jitter blur pass from the rendermonkey library. Its much faster than a seperable gaussian blur filter and gives superior results IMO. You dont get the pixely/boxy effect with it.

Well done

#5

Thank you :smiley: I’m adding normal mapping to it at the moment, so hopefully it will look even better!

Yep, that’s the way… float textures make everything so slow though so I might rewrite it to just to a contrast based HDR.

I’ll download this rendermonkey and have a look… Looks like I will need to reinstall windows though :frowning:

#6

Yes please, it’s the only requirement I don’t fullfil, so then I could atleast run the demo :slight_smile:

Endolf

#7

You should look at the Oat Scene Postprocessing presentation. It gives a variety of good blur/bloom filters. I quite like the first one - a separable gaussian with the sample points positioned so you get two ‘taps’ for the price of one. ;D

#8

Ohh that’s nice, I have a quick question on it though:

Is the tap distance just a function of the UV coords and the texture width so you can line your samples up on pixel bounderies?

And second, the gTexelOffset parameter is not being passed to the function, if that is the case how can the offset be correct because the texture width needs to be known? (actually are uniforms masked out in HLSL and they are passed just not explicitly like build in variables?) If that is the case I’m guessing they aren’t passed as tex coords because of the upper tex coord limit on most hardware (8 I think it is of the top of my head).

Care to clear this up for me?

#9

I haven’t read through the code for a while, but you’ve got the general gist of it. IIRC most of the code samples are just the basic algorithm, they don’t come with all the scaffolding you need to actually compile them.

If you’re using that method then you get much better results with well chosen weights. I found that hand-chosen weights were usually pretty bad, I ended up plotting a few graphs and taking a set of weights from them.

#10

Hehehe, you think thats bad! Try using 4 FP32 textures. Each texture stores just 1 component of the final color then bitshifting it all together in the end. Runs horribly slowly, but true 128bit bloom ;D

Being honest, the actual bloom pass give off a fake effect in games if over used. So a cheap sampling technique is better than a good quality one IMO. Just bung the rendermonkey blur passes and dont look back.

PS. The NV compiler gave quite a few warnings with regards to your shaders. More specificaly, sampler2DRect and texture2DRect aren’t defined in GLSL. Just use sample2D and texture2D

DP :slight_smile:

#11

I think that’s because I didn’t define the #version to be 110. If I change them to sampler2D it will not work as texture rectangles are being used. They require sampler2DRect, or so I am led to believe.

#12

I’ve been thinking about this, should I not be using arb_texture_rectangle and instead be using arb_non_power_of_two? That would stop me having to write duplicate shaders and also allow me to remove some of the extra render paths I’ve had to code for…

#13

Yup…ARB_texture_npot is useless now that arb_texture_rectangle is here.

DP

#14

Okay, new version of the demo has been uploaded, following features added:

Blur pass has been modified to use a shader based of the rendermonkey jitter blur. It looks much nice now (but I still have to do 3 passes)
Tone Mapping added (still in the very early experimental stages)
Updated UI

Float buffer dependency workaround will be pushed up tomorrow.

#15

You can now run the demo if you don’t have NP2 // float buffer support. It doesn’t look as good and the shader is a bit of a “quick hack” but it seems to work.

I have verified it on an 9800 with old drivers. mileage may vary, if it doesn’t work, and it should on your system paste the log… I like ironing out bugs.

Enjoy.

#16

works now on my 5900xt too.

#17

Works on my fx 5650 go now :slight_smile:

at 5fps, but I guess it’s an old card now :slight_smile:

Endolf

#18

Looks rather nice, but the bloom looks more dithered that i would have expected. If you’re interested, runs at:

41fps in Normal mode
38 fps in HDR mode
36 fps in Tone mode

on an Nvidia 7600