News First Serious Sam 2 benchmarks

[WilHarris]

http://www.bit-tech.net/news/2005/06..._2_benchmarks/

[chrisuk]

Awesome, shame I won't ever be able to afford that rig!

Just as a thought though, I didn't think HDR and Anti-aliasing were able to run conncurrently, as they are both post processing effects that are carried out just before the pixel data is saved. Or am I wrong? (the latter is more than likely )

[Bindibadgi]

Depends how HDR is implemented

[rupbert]

Some comments an how the game engine looks would be nice? Judging from screenshots alone, this game doesn't justify the term 'next-gen'...

[Darkedge]

HDR changes the lighting in the whole scene - is NOT a post processing affect
game looks just as fun as 1 - engine is quite nice but those screens too small to tell. Still with loads of bad guys n stuff

[Da Dego]

Uh, darkedge, HDR *IS* a postprocessing effect. I'm not sure if they somehow would have managed to avoid that by using SM2, but I don't really think so. Take a look at this thread for a recent discussion, and there are several others that you can read in the graphics forums and the discussion on HDR that happened about a month ago.

Back on topic, I loved SS1...I hope this is as good!

[relix]

Oh my god, they have witches!

*relix pees his pants in anticipation*

[Darkedge]

how can a post processing effect change the lighting in a 3 dimensional area - it's not just adjusting the brightness you know - somebody explain this better.

"HDR lighting, as with Half-Life 2, is done in Shader Model 2"
post processing with sharders then??

HDR as far as i know is a level of rendering quality for lighting to make an image more believeable, as such it is done in the main rendering path not as a post processing effect like AA

[The_Pope]

I'm sorry Darkedge - the word from resident graphics guru Tim is that HDR *is* a post processing effect. Does it matter whether it's post or not?

Crytek have told me "current hardware doesn't support FSAA in conjunction with rendering to (floating point) render targets.... the problem is that for true HDR you need a floating point target which you can render to - you can't have a floating point back buffer"

There's then some techno babble that wouldn't look out of place in a Beyond3D thread tbh.

However, it is an issue we'll be addressing in future coverage of HL2: Lost Coast

[Darkedge]

I'm afraid I believe Tim to be wrong
http://www.gamedev.net/reference/art...rticle2108.asp

"Render the scene with HDR values into a floating point buffer."

to me thats says it's in the rendering pipeline buy it's very nature and isn't a post processing effect. It may be possible to fake it with a post process but thats not true HDR.

I don't know whay they can't be concurrently used but one aspect may be the huge resources needed to store the 10bit values in the floating point buffer, which is also used for FSAA processing.

[Da Dego]

Originally Posted by Darkedge

I'm afraid I believe Tim to be wrong
http://www.gamedev.net/reference/art...rticle2108.asp

"Render the scene with HDR values into a floating point buffer."

to me thats says it's in the rendering pipeline buy it's very nature and isn't a post processing effect. It may be possible to fake it with a post process but thats not true HDR.

I don't know whay they can't be concurrently used but one aspect may be the huge resources needed to store the 10bit values in the floating point buffer, which is also used for FSAA processing.

You're missing a key element out of that whole thing, Darkedge. They explain through all the technical points further down that you start with a fully rendered scene, then (post-process, but they say it in many more words) apply a light probe to the scene and alter pixels on the image to create exposure and blur.

I see why you're saying that it should be a middle of the pipe effect, but think of it this way. Just like AA, you need a finished product before you can apply the HDR. The only way to know what is under- or over- exposed is to render the entire scene flat first, after culling. Then it's like putting a brightness map over the finished image, with plus or minus values.

Also, it's due to a technical limitation on the chips, because there is only one post-process section on a chip right now. Since you need the fully rendered scene so you can loop it back and make the transformations, you can choose to either subdivide pixels (AA) or create a brightmap (HDR). If another FPU and framebuffer were put onto the chip, it could theoretically work.

But as it stands, they are two separate tasks that both require the exact same hardware at the exact same time in the rendering process. Biggles has discussed this with ATi, NVidia, Valve, and Crytek and you can find the results of these conversations in other threads and articles on the HDR subject in the News, Articles, and Graphics Cards forums.

The way to HONESTLY implement HDR is not possible with current technology. What you are describing as "faking HDR" is all that can be done with current raster processes. Algorithmic rasterizing is exactly that: Faking..the entire scene, from start to finish, is an approximation, a series of effects layered over one another. The only way we will ever truly make light sources authentic is to begin developing true raytracing, which would require a move to solely 3-d environments (no more 2d) if the hardware were to become ubiquitous.

Hope that clears things up?

/* EDIT: A direct quote from the article you reference, once you get to the D3D code...

App Variables
If you open up the source code (you can find the link at the end of the article), you'll see a lot of global variables. These are used to hold textures and surfaces to render and post-process the scene.

The code itself, if you read through and follow it, illustrates that they are indeed implementing the HDR in post process.

[Darkedge]

indeed they are but they are also implementing it with rendering the scene with HDR values in the first place - so the answer here is not that it's a per or post process it actually a combination of both.

I see the limitations though so all HDR currently in real time is faked. Still looks good though.

[Da Dego]

Originally Posted by Darkedge

indeed they are but they are also implementing it with rendering the scene with HDR values in the first place - so the answer here is not that it's a per or post process it actually a combination of both.

I see the limitations though so all HDR currently in real time is faked. Still looks good though.

The app itself (all that blue and green code) renders a scene using 0f-1f (normal rendering), then applying a filter at the end which increases or decreases those values to the more extreme HDR numbers. As I said, it renders the scene flat first, then applies the HDR. There is a slight amount of per- process, but that's only the introduction of variables. So I suppose in that very limited portion, you are correct that it's both. Everything besides a few variables, however, is a post-effect.

Anyhow, you get most of the gist of this at this point, that it's a faked effect along with everything else, so I'll stop belaboring the point now and we can all enjoy the shiny pretties.

[The_Pope]

enjoy the shiny pretties

That's my recommendation: who cares if it's post or not?? I care:

a) it is l33t?
b) can I run it on my machine?

I suspect the answer to a) will be yes, but we will have to wait for code before we can answer b)