Great stuff, OTOH, no offence Eric but that ain’t a title. It’s barely a passable demo. I’m sure the tech is great but it has to have content, even the content it has doesn’t show the tech features I’d expect to convince me visually of the claims. Multiple moving light sources with overlapping shadows, emissive material properties and specular with gloss maps and of course the obligatory bumpmapped reconstruction of geometry on simplified meshes with plenty of detail in the scene and on skinned characters and maybe with & without ambient in some shots. Not all essential but mostly what you’d need at the very least to show it off.
I never claimed that it was a title of any kind, just a art-less tech demo.
Multiple moving light sources with overlapping shadows
Did you shoot the lights?
Cool it brother.
For a start it’s not so much to do with the art assets as it is to do with the way your demo is arranged. Took me a while to find that room with the swinging lamp, and that led me to ask the question “why is this lamp in this tight space?”: my only answer was that you were hiding a limitation of your renderer, ie. it’s speed and efficiency. You not only have to demonstrate what your renderer can do, but how fast it can do it and what cpu load it implies. Your demo should have more effects in the same place, to show that they can be used together with no significant cost.
You gotta sell your ass, boy.
By the way, your design chart is pretty vague. I assume that each module you detail is dependent on modules further up the hiearchy? In which case, a developer would have to resign himself to a 100% C4 engine path, which is too much of a risk…he may have his own libraries that he would like to use - you may do some things right, but you can’t be relied upon to have done everything right…you’re not perfect. A developer would want to have the choice of just using your renderer, for instance.
Just some thoughts, trying to help really. If the C4 engine is as good as you say, and has been around for over 2 years, I should have heard of it by now in the commercial sector, but I haven’t. You’re doing something wrong.
I just ran it on better hardware with better results. You need to have overlapping lights/shadows though. The projectiles don’t cast shadows, there’s really nothing visual in the demo that suggests it’s doing the ‘right thing’ TM, and of course there’s the art like you said, just bump mapping doesn’t cut it it’s gotta be bump mapped reconstruction of geometric detail but I don’t mean to bash it. Technically there are enough differences it the art path to make that a concern.
Nothing in the scene moves through the lighting for example a monster and none of the ‘interesting’ lights move.
Those early Doom 3 demos showed a monster wandering thorugh complex lighting for a reason. Just take it as food for thought, I’m not trying to bash it, just be constructive.
There’s a much bigger room in the A-shaped building where there are two swinging lights. If you stand in one of the doorways to this room, you’re actually getting hit by four light sources simultaneously. The light in the domed building being in a tight place has nothing to do with engine limitations.
Bump-mapped specularly is in there and should not have been too hard to find. Gloss mapping on top of that is also in there, but only on the main character, which you can’t see except in the reflective floor in the back of the A-shaped building.
BTW, in the room with the reflective floor (which, incidentally, is another place where you can see two of your own shadows), there is a secret passageway – shoot the walls.
The grenades actually cast shadows. The rockets don’t because they are usually obscured by smoke, but it would be trivial to turn shadows on for them.
The C4 Engine hasn’t been available for 2 years, but the features that I’ve mentioned have been functional for that long. I’m not really super-interested in licensing the technology – I’m primarily interested in making a game. Need to find some good artists who are willing to jump into a startup, though.
I would love to be able to have a monster running around with the bump-mapped detail, gloss mapping, etc, applied to it. The tech is all there. The problem is that I have no budget to get good art done. I know artists who would be willing to help, but they have full-time jobs and no extra time. If you have any solutions for this problem, please feel free to educate me.
Also, avoid running this thing on ATI hardware for the moment – their drivers suck.
Moreover I can see how deferred shading could cause problems with multiple light sources with independent shadowing for each light.
Deferred shading is no different than the traditional per pixel pipe in this regard. You simply interleave your shadow volume code between your lighting code. Or, read from your shadowmaps in the lighting shaders. Using a deferred system doesn’t change this.
Why? With early Z tests, you shade each pixel on the screen exactly once (times the number of passes needed to fit all your lights into the shaders).
Deferred shading definately wins at some point. When you’ve got 10 lights that touch 300k worth of geometry each, you don’t want to be drawing those batches of 300k triangles 10 times. Thats insane. Too many vertex buffer, material, etc changes as well. The average shader length for a deferred light is about 25-40 instructions, and you can draw a 200 triangle sphere to represent it. That’s going to be cheaper than drawing a batch of 300k triangles where the shader is about 10-20 instructions. With 6800’s new stencil early out tech, combined with traditional zbuffer early out tests, you can use the stencil buffer to mask the part of the sphere that actually touches the world, and get serious performance.
I’d say the very fact that they showed multiple shaders and said they had a shader editor and everything shows they are not using deferred lighting. With deferred lighting you need to apply the same shader to the entire screen.
The lighting equation must be the same per light (to keep things simple), but you can use whatever shader you want when writing colors out in the first pass. This is where a majority of the modifications happen anyhow, right?
If I had a level that consisted of over a million triangles, I’d definitely place my bets on the deferred pipeline.
Which shadow algo to use is still up in the air though. Shadow volumes are actually faster in some cases (especially if you use a different model, with less geometry for your shadow volumes). Shadow volumes also benefit from going into the distance, as they occupy less screenspace when this happens. Shadow maps are faster in other cases (static lights for example beg to use shadow maps).
Originally posted by John Pollard:
The lighting equation must be the same per light (to keep things simple), but you can use whatever shader you want when writing colors out in the first pass. This is where a majority of the modifications happen anyhow, right?
[/QB]
In the first pass,you write out vertex position,normals and texel colors.These are standard info used by all the next passes,you can’t do anything different with them.
Anyway,just some thoughts about using multiple shaders with deferred shading,using as base the tutorial in www.delphi3d.net:
Let’s say we have 10 different shaders,for 10 different kinds of material.We can map a shader to a float value,say shader1=0;shader2=0.1;shader3=0.2 etc.We can pass that as a parameter in the first pass and store that value in the 128-bit fat-buffer.Then,we render a second pass with a depth-replacing program and we write that value to the depth-buffer.Hence,fragments that should be processed by the first shader have z=0,for the second z=0.1 and so on.We can then do ten passes for each shader and use early ztest,or possibly some extension like depth_bounds,to exclude all the fragments that are not to be processed by the current shader.That sounds like a lot of passes,but really there is not much additional work in the vertex pipeline,and the total amount of the fragments processed by the shaders doesn’t increase.
In the first pass,you write out vertex position,normals and texel colors.These are standard info used by all the next passes,you can’t do anything different with them.
In the color channel, you can apply EMBM, add two textures together, add an EMBM’d effect with a panning wall texture, modulate a detail texture with the wall texture, etc. The possibilities are endless. This effect (created by the artist), will then get combined with the lighting.
Originally posted by John Pollard: Deferred shading definately wins at some point. When you’ve got 10 lights that touch 300k worth of geometry each, you don’t want to be drawing those batches of 300k triangles 10 times. Thats insane. Too many vertex buffer, material, etc changes as well.
I’m guessing it’s state change and fragment program complexity that’s gonna kill you, rather than the number of vertices.
Compiled vertex arrays were the super-sexy, en vogue thing a couple years ago before hardware transformations. I don’t think transform is ever a bottleneck anymore.
Anyone try CVAs on modern number with a very large number of passes? With early z-reject and each pixel only being hit once, maybe there are cases where transform is the bottleneck.
I wouldn´t be so sure about transform not being the bottleneck anymore.
It depends on what you are doing. If you need to transform your polys for each and every light in the scene, this can easily double the amount of traingles needed as when you transform everything only once.
So, even if that is still not your main bottleneck, you will on the other hand get those triangles for free, if you don´t need to transform them multiple times, meaning, that you can have VERY detailed levels, which Unreal 3 actually does have !
They said to have 1000000 triangles / polys in a scene! I call that f****** DETAILED !
All in all its not about reducing the workload of the GPU, it´s about reducing redudancy and instead do something, which has visible impact.
John Pollard, I don’t agree with a lot of what you’ve written, but the most exaggerated claim is w.r.t. standard rendering & lighting. A more conventional rendering path can use fragment lighting with positions of multiple lights sent once at the outset especially with the flow control in NVIDIA’s hardware. Heck you could do the transform to tangent space in the fragment shader or even do the lighting in object, world or eye space, take your pick. It doesn’t have to touch geometry for each light. In addition for many lights you either need a lot of framebuffer storage for local light positions and/or many screen space passes, & that’s without considering issues like shadow casting. I mean you have to do exactly the same as a fragment light transformation and itteration or render light positions to the framebuffer so the playing field is level at best.
More important than all of this though is the fact that it’s merely an optimization, if you can make it go faster good luck, but that’s all it is, it defers shading to a post visibility determination. That’s where it’s supposed to be a win, I’m very skeptical it can ever be faster than a more conventional approach & the kinds of fragment shaders that can be implemented now, but whether it’s true or false, it doesn’t herald the next jump in visual quality which was the original issue of contention.
If it’s faster prove it with code, but to me it seems absolutely obvious that with improving intruction sets and zbuffer optimizations, deferred shading is less of a win with every generation of new hardware, even as the hardware enables it as a possibility.
Eric, I ran it on a 9800 Pro and it seemed to be functional. I saw the specular but I didn’t see any moving lights I saw the reflective floor but never noticed myself reflected although I did see my own shadow in places. I never fired a rocket (didn’t know it was possible), just the primary weapon with no shadows.
I’m very skeptical it can ever be faster than a more conventional approach
Sorry, I’m not trying to ruffle any feathers or anything. I’m actually using my personal experience, and thought I’d chime in for anyone that was interested. I’ve just been really interested on the subject of deferred vs conventional lighting myself, so this thread interested me.
I’ve implemented both pipes. The conventional pass per light wins where there is not many material/state changes, and not much overdraw. Deferred shading seems to win when the scene starts to approach large amounts of triangles with large amounts of overdraw, and lots of state changes. The more complex your scene is, the more types of materials the artists use, etc, the more deferred shading looks real nice, and starts to win (in my experience).
Even in situations where it’s a draw, deferred lighting is really nice imho, and will be my personal choice going into the future. You don’t have to have such a light centric pipeline anymore. Your primitive batching system gets really complex when you want to try to get maximum batching using the conventional way, it’s all just so simple with deferred lighting.
But right now, the conventional method seems to be the best with current generation of cards, but deferred is looking really good for the future.
No offence taken. We all have experience to draw on.
You say that a conventional approach looks looks good for now but deferred looks good for the future. So all we disagree on is what’s in the crystal ball. Time will tell.