DeathKnight
Regular
You missed the gist of the statement. It doesn't have the ram size limitation that those two systems have, ie. it has more ram to work with.marconelly! said:
Provocative comment by Id member about PS2 (and Gamecube)!
- Thread starter bbot
- Start date
marconelly!
Veteran
SH3 shadows use the same method as those in D3 except that instead having them all sharp and edgy/polygonal looking like in D3, they blurred them to make them look soft. The blocky look is unavoidable using this method, and is present in D3 too because the shadow volumes are done using the same geometry as the actual low poly models, and the models themselves look a lot more impressive due to the usage of normal maps. Splinter Cell uses shadow maps and those have pixelization whenever the shadow map resolution becomes insuficient. It's pretty horrible in SC actually whenever you zoom into your character so that you can shoot - You see shadowmap pixels literally twisting and shaking on his face.
Not sure about the one light thing, but I think that's true. However, the decision that not every tiny object casts the shadow is purely a designers/programmers choice to speed things up as the stencil shadowing method allows you to exclude objects from the calculation.
DeathKnight
Regular
Like what? It's certainly got enough main memory bandwidth as well as rendering bandwidth to produce some of the best visuals in the console world. You're trying to beat a dead horse here.Paul said:
You mist the gist too. It has nothing to do with the PC side of things. Between the three consoles the Xbox is at the least disadvantage concerning memory size.ChryZ said:
Correct me if I am wrong, but doesn't the fact that the SH3 shadows are somewhat blocky imply that that they are using texture projection to actually draw them in?
Isn't this completely different to the method employed by Doom 3?? Ie, no deferred-rendering?
They may both be using stencil buffers to find the shadow volumes, but one is doing it a whole lot easier than the other. Is it really that comparable?
Also, since when does the Cube have vertex processing limitations? Do my eyes decieve me? Do people still think Factor 5 are lying?
Isn't this completely different to the method employed by Doom 3?? Ie, no deferred-rendering?
They may both be using stencil buffers to find the shadow volumes, but one is doing it a whole lot easier than the other. Is it really that comparable?
Also, since when does the Cube have vertex processing limitations? Do my eyes decieve me? Do people still think Factor 5 are lying?
Panajev2001a
Veteran
Bohdy said:
Well, when I see in a room some areas previously lit ( even in barely ) becoming considerably darker right after I turn my flashlight on, well I'd say that I suspect a normal use of the shadow volumes with stencil ( stencil shadow volumes ) algorithm as it has been described for DOOM III in several occasion.
Of course, they might be calculating where different rays of light cancel each other due to differences in phase and doing it per vertex, but I doubt it
Megadrive1988
Veteran
XBox has the largest main memory bandwidth of the three consoles.
6.4 GB a second, compared to PS2's 3.2 GB a sec. and GC's 2.6 GB a sec.
However, Xbox's main memory bandwidth has to be used for everything.
CPU, Graphics, Audio, etc.
Both PS2 and GC have massive bandwidth on their graphics chips, thanks to embedded on-die memory. 48 GB a sec for PS2's GS with its 4 MB memory. The Cube's Flipper has 10 GB a second for textures alone, and probably close to 20 GB a second total for the whole Flipper, with it's 3.12 MB memory.
XBox lacks an equivalent on-chip memory like PS2 or Cube. There is a TINY amount of cache on XBox's NV2A with large bandwidth but this is not the same as having several MegaBytes on your graphics chip like PS2 and Cube.
6.4 GB a second, compared to PS2's 3.2 GB a sec. and GC's 2.6 GB a sec.
However, Xbox's main memory bandwidth has to be used for everything.
CPU, Graphics, Audio, etc.
Both PS2 and GC have massive bandwidth on their graphics chips, thanks to embedded on-die memory. 48 GB a sec for PS2's GS with its 4 MB memory. The Cube's Flipper has 10 GB a second for textures alone, and probably close to 20 GB a second total for the whole Flipper, with it's 3.12 MB memory.
XBox lacks an equivalent on-chip memory like PS2 or Cube. There is a TINY amount of cache on XBox's NV2A with large bandwidth but this is not the same as having several MegaBytes on your graphics chip like PS2 and Cube.
marconelly!
Veteran
If they've been using texture projection, those shadow textures would have to be of some insane resolution as to not become *really* blocky when the shadow projects far away from the object (as is often the case in the game) There's also no distance fallof in the shadow softness which would also have to be present in the shadows if they were texture based. Shadows only look 'blocky' because they are still polygon/volume based (although blurred in the post-process before blending to hide that) not because they have pixelated edges due to insufficient shadowmap resolution
Stencil shadows typically look sharp because they're a pixel-level effect. Each pixel can only be in shadow, or not in shadow.
In order to get "proper" soft shadows, the most accurate technique is to do a whole bunch of different stencil volumes projected from a selection of points inside the volume of the light-source (soft shadows are typically caused because light-sources are not single points, but light emited from a volume of space). You accumulate the result and blend between the lit and non-lit values based on how many volumes overlap.
That's exceedingly expensive even for a small number of samples, and you probably need quite a few to avoid banding effects. There are tech-demos of it, but it's a little way off being practical in a game situation (at least for a complex scene). Hopefully someone will come up with something cleverer and we won't need so much brute force.
What SH3 does, is to just blur the shadows in 2D before applying them to the scene. That, as people have noticed, creates some nasty artifacts.
Firstly the blur filter they use is not particularly sophisticated. It's probably just a down-sample to a lower resolution, followed by using the standard bilinear texture filter to expand up again. That makes it look a little blocky. You can do nicer filtering operations with jittering and variable sized sampling, but it's a bit more expensive...
The other problem (and for me it's a more serious one) is that you get odd "halo" effects around the shadows. The problem is that the stencil shadow is essentially in 2D once you've drawn it. If you just blur that, you get a nice soft edge to the shadows, but not all of them should look like that.
On a flat plane, like the floor, any blurring looks good because you are blending stuff together which is physically adjacent. However if (for example) the character is in front of that shadow, and the character itself is not shadowed (perhaps the light is behind the camera and the character itself is *casting* the shadow), then the shadow pixels on the floor will be blended with the non-shadowed pixels on the character, and so there will be a strange blurred area of light around the character.
This happens wherever a lit object is in visible in front of a shadow. The lighting values get blurred together wrongly, as you would really *expect* a very sharp edge to the shadow.
One potential solution would be to do edge-detection on the z-buffer, in order to create a mask for the blurring operation. That might work...
In order to get "proper" soft shadows, the most accurate technique is to do a whole bunch of different stencil volumes projected from a selection of points inside the volume of the light-source (soft shadows are typically caused because light-sources are not single points, but light emited from a volume of space). You accumulate the result and blend between the lit and non-lit values based on how many volumes overlap.
That's exceedingly expensive even for a small number of samples, and you probably need quite a few to avoid banding effects. There are tech-demos of it, but it's a little way off being practical in a game situation (at least for a complex scene). Hopefully someone will come up with something cleverer and we won't need so much brute force.
What SH3 does, is to just blur the shadows in 2D before applying them to the scene. That, as people have noticed, creates some nasty artifacts.
Firstly the blur filter they use is not particularly sophisticated. It's probably just a down-sample to a lower resolution, followed by using the standard bilinear texture filter to expand up again. That makes it look a little blocky. You can do nicer filtering operations with jittering and variable sized sampling, but it's a bit more expensive...
The other problem (and for me it's a more serious one) is that you get odd "halo" effects around the shadows. The problem is that the stencil shadow is essentially in 2D once you've drawn it. If you just blur that, you get a nice soft edge to the shadows, but not all of them should look like that.
On a flat plane, like the floor, any blurring looks good because you are blending stuff together which is physically adjacent. However if (for example) the character is in front of that shadow, and the character itself is not shadowed (perhaps the light is behind the camera and the character itself is *casting* the shadow), then the shadow pixels on the floor will be blended with the non-shadowed pixels on the character, and so there will be a strange blurred area of light around the character.
This happens wherever a lit object is in visible in front of a shadow. The lighting values get blurred together wrongly, as you would really *expect* a very sharp edge to the shadow.
One potential solution would be to do edge-detection on the z-buffer, in order to create a mask for the blurring operation. That might work...
DeathKnight
Regular
Even when the Xbox has to share that main memory bandwidth it still comes out with roughly 5GB/sec for the graphics alone. The Cube and PS2's large caches help with repetitive vertex, pixel, and texture information. The NV2A's cache still makes out just fine with ~32GB/sec of bandwidth though. The higher amount of ram and higher bandwidth to the ram allows it to push larger amounts of ambiguous data.Megadrive1988 said:
In the end I still don't see any games on the Cube or PS2 that best the Xbox's higher-end titles as far as texturing goes (or anything else really), yet you're trying to insinuate that the Cube and PS2 are better suited for bandwidth intensive rendering. That doesn't seem to be the case given the results.
Most high end Xbox games: 30hz.
This is because of the bandwidth, noone can deny this. Sure it does produce better graphics though.
Why are you talking texturing here? It's framerate. And most high end Xbox games don't have as high as a frame rate as high end PS2+GC games, this because of the bandwidth.
It does show that Cube and PS2 can handle better then Xbox under pressure. Take a look at MGS2's tanker scene, sure some may argue bad port, bad port but Konami tells a different story.
[/code][/quote]
faf, mrWibble good posts
right thanks.
we are not (I hope) cheifly berating Chap here (unless someone wants to clue me in on the lynching ).
pretty much.
there will be, it's set to run (in the literal meaning of the word) on slower cards. if a geforce3/4 hybrid on a closed system can't get upto par on performence alot ppls are gonna have questions
yes, but with enough limited ram to turn the problem into one of memory and data management. (hell I'm even excluding the stuff that already provide a barrier to ono-to-one porting).
when you move away from fixed function T&L ops gekko becomes a limiting factor.
they are in cases where data does not overflow there respective caches I imagine.
right thanks.
we are not (I hope) cheifly berating Chap here (unless someone wants to clue me in on the lynching
).pretty much.
there will be, it's set to run (in the literal meaning of the word) on slower cards. if a geforce3/4 hybrid on a closed system can't get upto par on performence alot ppls are gonna have questions
yes, but with enough limited ram to turn the problem into one of memory and data management. (hell I'm even excluding the stuff that already provide a barrier to ono-to-one porting).
when you move away from fixed function T&L ops gekko becomes a limiting factor.
they are in cases where data does not overflow there respective caches I imagine.
Similar threads
