Real-Time High Dynamic Range Image-Based Lighting

Oops, didn't see that. Anyway, I had it running at standard 1024 x 768.

 

The skull is amazing!

 

Just a quick thought. Anybody fancing try 3DAnalyze on this demo to see what happens when you force the _pp modifier? The program does "work" on this demo - well, at the very least it can display fps and polygon count correctly.

 

Well, if 3DAnalyze uses the _pp modifier on every PS 2.0 instruction, then if these programs have any dependent texture reads, there's a good chance for there to be visual glitches, but the color quality should be essentially identical.

 

One has to wonder why the Geforce FX is rendering it in 8 bits per channel. I wish someone with a FX would test it with the FP32 43.00 or 43.03 drivers. I have a feeling that when someone does it, it will revert to running in 16FP like the radeon rather than whatever it is now... FX12, FX8????

 

For those having trouble running the app, I got it to work by using Driver Cleaner 1.3 (www.driverheaven.net) and then going back to the 3.1 drivers.

Regards, Chris.

 

This is because the program runs in a window. When you maximize it it still leaves the top and the bottom bar unused.

 

According to the guys at Rage3D, the DX8 version looks like this on Radeon 8500 :

 

All instructions on the FX are executed at at least 12-bit integer accuracy. The only place where 8-bit integer may be used is in texture filtering (though even there the calculations are probably done in 12-bit).

But the FX supports no output format greater than 8 bits per channel, though it does have a 10-bit DAC.

Personally, I'd like to see nVidia introduce a format that has a 64-bit floating-point back buffer, and a 10-10-10-2 front buffer (2-bit alpha would be meaningless, but so would adding one bit to any two of the channels, as the DAC is 10-bit).

 

Has anybody done a full DX9 Caps check (specifically texture formats) with a NV3x? I know it's something Dave likes to do in reviews, but I'm too tired (read "lazy") to go and look right now...

 

We've done a preliminary scope of the cap for GFFX and as of the 43.45 driver NV30 doesn't support any float texture targets.

 

Ive got an FX Ultra 5800 - and even though it says something like 6fps in the program when its running - it really runs like its 30fps or something like that...

Looks pretty darn amazing...


... but no - doesnt feel anything like 6fps

 

I fired off a couple of questions to Masaki Kawase, the author of the demo. He was very kind to reply so quickly, and with plenty of detail (especially given that English is not his first language):

1. How many passes are required when using all of the effects?
I use many many passes.

- DOF : 2-3 passes (Thease are very heavy processings becouse using full-resolution buffer and complex pixel shader)
- Some "reduced and small-blurred buffers" generation for some effects : 7 passes
- Bloom : 12 (Thease are very fast because using very small buffers)
- Halo : 5 (Thease are fast, too)
- Star : 6-24 (Thease are heavy because using many passes)
- Ghost : 2

"Default settings" use about 40 passes for the all effects.
And almost all thease processings are using reduced buffers.

. Are you using the standard DX multisample method for FSAA or a pixel shader method?
I use the pixel shader mothod for applying motion-blur effect and using arbitrary number of samplings unsupported by the device (12, 16, etc.)

3. How many polygons are used for the different models?
The skull model has about 60k polygons.
The teapot model has about 10k polygons.
Sky box has about 4k polygons.

Rendering is 2-pass process (Z-pass and color-pass) per single sampling. But the "rotating spheres demo" uses only 1-pass process per sampling.

4xMultisampe repeats the above process in 4 times.

4. Do you use the _pp hint modifier for any of the pixel processing?
Yes. All of the shaders use _pp hints.

The demo has some rendering modes dependeng on the current graphics driver.

For example, if the current driver doesn't support the "high-precesion texture formats", the demo uses lower precision textures and simulates the high precision rendering by packing and unpacking RGB-E process in almost all pixel shaders. This causes that image quality and performance down.

GeForce FX's "current driver" doesn't support the high precision formats. Of course the hardware is supporting it, but can't be used with D3D yet...

What a top chap!

 

Yep, thats what I get

 

That's what i get too, with both a 8500 and a 9000