Shadow 'bug' also present in DX: Invisible War

[killahsin-[CE]]

There are currently two choices:

1) Pre-computed light- and shadow-maps along with their associated problems (i.e. shadow overlap) but great performance; or

2) Full real-time lighting and shadows but at a huge performance hit.

A unified lighting system is great for large outdoor areas...if your computer is from 5 years in the future. Valve picked the best option for today's hardware.

quoted for empahsis
+1 informative


But I want to emphasize all shadow models currently in use including those planned for u3 have the same bugs. All have workarounds not all work arounds are 100%. In some instances in doom 3 you can replicate the shadows on top of shadows that you see in hl:2 as well, as shadows bleeding through non static objects. I.E. entities and mesh's. Until we have the computing power to make shadows actually shadows, rather than directional vert projections or z fail shadow volumes. You will see issues like this prevalent.

 

[kaellinn18]

no.

Yes, thank you for proving both of my points. In the second shot of your picture, there are NOT 600 active pixels. Your monitor has a fixed resolution. Whether or not two objects intersect at a pixel is irrelevant; it remains ONE pixel. You simply change the value of that pixel as necessary. Also, look at all of the checks you had to make in order to remove the unnecessary shadow. There's no way that would increase performance. I'm sure it could be optimized, but you'd still end up chewing more CPU cycles. And this would have to be done for every pixel that intersects a shadow (more likely all pixels).

or destory them?

I don't know what you mean.

 

[killahsin-[CE]]

no.

or destory them?



this is very simplified.. ATTACHMENT:

nice graphic answer to solvce the problem but mind telling me how you plan on adding that to a real time method? Code wise?

 

[killahsin-[CE]]

First off, there's always the same number of pixels. Now I'm not sure how many passes that the Source engine makes to determine pixel color (I'm pretty sure it depends on what graphics card you're running), but fixing this shadow bug wouldn't change a thing in terms of the number of passes needed, just in terms of adding in the actual color. The only thing affecting performance would be the checks that would need to be implemented to determine if shadow needs to be applied (which would DECREASE performance, never increase). I've heard talk that this "bug" is a map design error, and not an engine error. I'm not sure which is true, but there's no way fixing it would ever increase performance.

The truth is the bug is in fact a map design error. It's all about the properties one dictates to each mesh. In all honesty its a bit of both, the bug is prevalent in all shadow methods. The real issue is there are work arounds and properties you can add to each static object mesh and so forth to get shadows to not bleed through. This is why you see it on some objects and not all. Doom 3's design team most likely due to carmacks graphic dilegence was very on top of doing work arounds for almost every instance. But if you play around railings long enough you can recreate the same errors. Honestly its just a time issue.

 

[She]

nice graphic answer to solvce the problem but mind telling me how you plan on adding that to a real time method? Code wise?

valve has top-notch programers no?

 

[She]

Yes, thank you for proving both of my points. In the second shot of your picture, there are NOT 600 active pixels. Your monitor has a fixed resolution. Whether or not two objects intersect at a pixel is irrelevant; it remains ONE pixel. You simply change the value of that pixel as necessary. Also, look at all of the checks you had to make in order to remove the unnecessary shadow. There's no way that would increase performance. I'm sure it could be optimized, but you'd still end up chewing more CPU cycles. And this would have to be done for every pixel that intersects a shadow (more likely all pixels).



I don't know what you mean.

yes.. 2 overlapping pixels show as 1 pixel..
but the engine still renders them both.


let me give you another example in part 2..
ATTACHMENT:

 

[Falcon(Nate)]

She, I understand what you're saying.

This would NOT fix shadows going through other physics objects, however, which is the source of the shadow problem.

Checks for every pixel of a shadow sound like a bad idea. Shadows really are additive in the real world. If 2 shadows intersect, the place where they overlap is DARKER. (Try this with 2 or more light sources. This effect is usually easy to see on say, a basketball court or high school football stadium at night.)

The problem isn't that shadows overlap, it's that they overlap because they go through objects when that isn't the case in the real world. Thus, your check is unnecessary. Your check would not prevent single shadows from falling through other physical objects, which is the source of shadow overlap.

EDIT: Basically, She, your solution would work for one light source. But if any more light sources were added (which is possible in mods, etc.) your shadow fix would break down because shadows which SHOULD overlap would appear as one shadow.

 

[She]

This would NOT fix shadows going through other physics objects, however, which is the source of the shadow problem.

yes i know.. that is a different thing..

And i would draw another example for that one too, but i have to
work..

Try this with 2 or more light sources.

HL2 shadows are only cast from 1 lightsource.(objects only cast 1 shadow)
bah!.. but i know what you mean!.. that is a different story.

 

[DigitalAssassin]

'She' obviously knows what (she/he)'s talking about. Looks to me like it'd be possible to program, and if it can be fixed in the code before it hits the graphics processor, it could make up for the lost time in calculating. Still looks like a brute force method, or would only overlapping shadows be isolated for analysis?

 

[Homer]

Deus ex 2 was so bad that I dont think it matters to anyone if the shadows are a little odd.

 

[Falcon(Nate)]

She's solution would work for one light source, I'm not disputing that.

It is pretty brute force however. All shadows would still have to be drawn and then checked for overlaps. That check is not there currently. I'm not sure if it's even possible with the way shadows are currently drawn. (It appears that shadows just take appropriate areas and make them darker by a set amount. To be able to put in checks might take a re-write of the existing shadow system, and that rewritten system would then be incorrect when more than one light source is present.) Seems like a step backward instead of a step forward from a programmer's point of view. Doesn't appear to be an easy way to optimize it either. All of the shadows would still have to be drawn, then overlapping regions accounted for, which would have to be checked in every shadow pixel.

The actual operation to draw to the screen should take the same amount of time, but checking shadow overlap would take more time before the draw operation occurs. Whether the framerate drop would even be noticable, I honestly have no idea. 0.1 FPS drop or 10 FPS drop, a drop would still be there. I'd like to see mod teams try this when the SDK comes out.

 

[ahardy668]

Edit: NM