Power Render X Movies / stencil shadows

[Chris Egerter]

Some new Power Render X movies and screenshots have been posted at:

www.powerrender.com/prx/

The engine still have a lot of work to do, but the rendering portion and shadow algorithsm are pretty much done and being optimized further.

If you want to talk about shadows I would be happy to explain some of the techniques used.

 

[Grall]

Hm, BSP levels? Well that kinda kills the prospect of deformable level geometry dead doesn't it?

What's so next-gen about it really? Not bashing it, just wondering. To me, the next big thing is deformable geometry, a game where your fusion cannon that turns badguys inside out and splatter them across walls actually brings DOWN walls if fired right AT the wall!

Now that would be cool. Leaving a silly little decal black spot, that's totally boring stuff.

*G*

 

[Snyder]

What's so next-gen about it really? Not bashing it, just wondering. To me, the next big thing is deformable geometry, a game where your fusion cannon that turns badguys inside out and splatter them across walls actually brings DOWN walls if fired right AT the wall!
Now that would be cool. Leaving a silly little decal black spot, that's totally boring stuff.

I think I remember an interview with one of the programmers of Prey. It also showed very impressive scenes where exactly that happened. (On a P166 with a Voodoo2!)

 

[Saem]

Deformable geometry on a large scale is still far away in my eyes. The amount of physics that need to be done is still too far away. Well it is if you want comparable graphics, AI and other stuff plus this.

 

[ben6]

very nice shadows Chris.

 

[Chris Egerter]

Deformable geometry isn't new. Red Faction did it a couple years ago. There is nothing stopping us from adding deformable geometry inside a larger BSP level that you can't destroy. The BSP at least gives you a world boundary that escape by making a tunnel. There are very few things in computer graphics that are brand new. As hardware advances, things become more feasible to do in realtime.

The lighting and shadows are the next gen part. Using multiple passes per light to add non shadowed areas to the frame buffer is a big change to the old way of drawing a scene. Per pixel ambient reflections using projected cube maps, and post processing techniques for blurring and glows will require DX9 class hardware. We are focusing on per pixel details to get a higher quality rendering rather than polygonal techniques like deformable geometry.

 

[Tahir2]

I would love to see higher geometry used in the scenes. The model looks pretty detailed but the background poly and texture detail could be upped a little? Im sure it is just a trade off...your engine implies it is scalable... no?

 

[Chris Egerter]

I have not spent a lot of time on art yet, since the requirements for the engine may change yet. For now I just have a simple level, character and a few textures to play around with.

Can definitely use much high resolution textures and bump maps using compressed textures. The character model is actually too high (around 5k polys). We're going to aim for around 1500 so there can be several characters on the screen at once. An object with 5k polys can easily use up 40-50k polys in the engine once lighting and shadows are applied.

The level is too detailed as well. It has 5000 polys in one little room. Actual levels will be spread out more and take advantage of PVS to cull out the parts you can't see.

BTW this is currently running at about 30 FPS in 640x480 on a Quadro FX 1000.

 

[Gump]

Just out of curiousity, when are you planning on having this engine completed?

EDIT: Just saw on the site it is schedule for mid 2003; is that still valid?

 

[Chris Egerter]

Hopefully it will be usable form later this year.

 

[K.I.L.E.R]

I just hope you knock down the requirements a lot more for us 9700 Pro and P4 1.8GHz users.

Not everyone has the latest stuff.

 

[NeARAZ]

If you want to talk about shadows I would be happy to explain some of the techniques used.

Are the shadows for static geometry and static lighting precomputed (or "baked into" the geometry)?

Do/can you use simplified shadow caster geometry (eg. high poly character for the display, low poly for the shadow volume)?

Are the shadow volumes generated on the CPU or on the GPU?

 

[Chris Egerter]

All shadows are computed on the CPU, and optimized for light attenuation and silhouettes to cut down fill rate. No wasteful infinite shadow volume methods. Volumes are cached in memory, so they are only recomputed if the caster or light changes in some way.

Most of the time you'll have lots of static optimized volumes that require no GPU or CPU work to draw, and a few dynamic volumes from characters or moving parts of the level.

The shadows are not baked into the geometry, so any light can move or be turned off at any time. You cannot use simplified shadows for the characters. However since each character is drawn using 2 or 3 passes per light, you probably don't want high poly characters anyways.

I really think this type of rendering will be used a lot in the future. It is fairly slow right now but as hardware gets faster we'll be able to dump more polygons into a scene.

 

[Luminescent]

The engine looks great in its current condition, I only have a few "feature" suggestions which might be beneficial for future use.

Here they are:

-An algorithm which detects a DX9 part and generates the shadow volumes in the geometry engine (like 3DMark 03), while defaulting to a cpu based method for <DX9 parts (if it's no trouble to code with DX9 vertex shaders; never tried it myself).

-"Light and view vectors normalized with math, rather than a cube map. On future hardware this will likely be a performance improvement due to the decrease in bandwidth, but current hardware has the computation and bandwidth balanced such that it is pretty much a wash. What it does (in conjunction with floating point math) give you is a perfectly smooth specular highlight, instead of the pixelish blob that we get on older generations of cards (John Carmack)."

Carmack seems to have added this as a novelty feature in the Doom 3 engine. It would be a nice feature to incorportate into any engine which addresses hardware capable of PS1.4 (out with the cubemaps!).

-A high fidelity rendering path (high range dynamic lighting, procedural per-pixel lighting, gpu generated shadow volumes, etc.) alonside a more rudimentary one would be nice to include in your engine and make it scalabe for years to come.

 

[Grall]

ChrisE:

It's cool that you do work with lights and shadows and stuff like that, but to me that will just lead to more 11th hour type games, but with a movable camera. IE, pretty graphics but low interactivity.

Deformable level geometry isn't some silly gimmick, it's never been exploited properly in ANY game so far. Pixel shading and post-processing effects is just paint on the surface. I want programmers to reach in deeper!

Making tunnels in fixed BSP geometry is only half-assed stuff that Duke Nukem did more than half a decade ago. Time to do something new, something radical.

A gaming engine where the player could (theoretically) level the entire playingfield, now that would be something.


*G*

 

[Chris Egerter]

I guess you didn't read the whole Nvidia rant about how 3DMark03 uses GPU shadow volumes and skinning for everything and that is not how real games will be done. I totally agree with them.

Why make the GPU extrude shadow volumes when 90% of the scene only needs the polygons drawn without any changes from the previous frame. The real bottleneck in our engine is fill rate, and you can do some nice optimizations on the CPU to cut that down.

I am just getting started on PS 2.0 and will be looking at combining diffuse+specular passes, and other opportunities.

I have done some work with HDR but it's far too slow for this engine. I plan on doing some tricks to emulate some of the glow effects without doing full HDR.

 

[NeARAZ]

I guess you didn't read the whole Nvidia rant about how 3DMark03 uses GPU shadow volumes and skinning for everything

The thing is it's very convenient to generate (dynamic) shadow volumes on the GPU as the CPU in most cases has better things to do, plus it brings you other benefits (eg. static geometry). And for games the things that nVidia is ranting at ("it takes 4x the triangle count", "performs skinning many times" etc.) aren't neccessary in all the cases: you can have shadow volumes with self-shadowing and even a simplified mesh, all done on the GPU...

Of course, it depends on the situation.

What are the "optimizations" that you run on the CPU, in particular, do they lower the fillrate requirements? And can't this be done on the GPU instead?

 

[Chris Egerter]

Doing static geometry is where GPU shadow volumes lose. Why have the GPU do all that work when the shadow volume is the same as the previous frame and probably the same for the lifetime of the application.

Skinning is a huge issue too. In this engine a skinned character on the GPU would need to be skinned 1+4*number of lights. With CPU skinning it is done once, regardless of how many lights.

Right now the bottleneck is fill rate, due to shadow volumes and per pixel lighting. Using the GPU to perform skinning and shadow extrusion is going to help transform the vertices faster, but will be much worse in terms of fill rate.

For instance say a character's head is within a light's radius. With CPU shadows you can ignore the polygons below the neck and only draw the head's shadows. With GPU you are sending all the polygons to the card regardless. The silhouette calculations on the CPU are also a big savings in fill rate.

 

[NeARAZ]

For instance say a character's head is within a light's radius. With CPU shadows you can ignore the polygons below the neck and only draw the head's shadows. With GPU you are sending all the polygons to the card regardless. The silhouette calculations on the CPU are also a big savings in fill rate.

But you only send more vertices to the GPU, so the shadow geometry is made of more vertices; but in gereral the shape of the geometry is the same - so there's the same fillrate cost.

 

[Chris Egerter]

If you extrude each polygon a different amount, yes it will be nearly the same in fill rate. However I don't see a reason to bog down GPU with vertices. In the future when fill rate gets better our vertex traffic will already be down to a minimum as well.

We are making sure you can turn off shadows and bump mapping so if you have a slower cpu/card it will still run at +120 fps. There are a lot of combinations of effects that can be toggled to give a suitable frame rate on any machine.