Render Player's Own Shadow

-WildCat-

When playing NS2, I would love to be able to see my own shadow cast onto the environment for two reasons:

1. It would look awesome.
2. It would allow you to see if your shadow is giving away your position. (Particularly useful for sneaky skulks.)

I get the feeling that the only reason why the player's own shadow is not rendered is because your own third-person model is not rendered in the scene.

Now, I'm not suggesting that you add that in. I don't feel the need to see my own legs in this game and I realize that there would be a lot of work involved in getting that working nicely.

However, there must be a way to render the player's shadow without also rendering their own third-person model in the scene. Surely it can be set up that the third-person model of the player is only rendered while the shadow maps are being calculated but not when the actual player's perspective is rendered.

bp2008

+1

I like that shadows matter enough to make this a problem. In so many games, they are just eye candy.

EgoGamer

Agreed!

Would also like to see an option to only render your own shadow for players on low-end machines. Assuming that's possible; With my limited knowledge of coding it might as well be magic.

xen32

EgoGamer wrote: »

Agreed!

Would also like to see an option to only render your own shadow for players on low-end machines. Assuming that's possible; With my limited knowledge of coding it might as well be magic.

Well then, I'd like to see "only skulk and lerk shadows, including your own" option

CrushaK

-WildCat- wrote: »

However, there must be a way to render the player's shadow without also rendering the their own third-person model in the scene. Surely it can be set up that the third-person model of the player is only rendered while the shadow maps are being calculated but not when the actual player's perspective is rendered.

It surely can, but it would probably involve changing their rendering pipeline, otherwise we would have seen it by now, I think.
Or the reason is performance savings, since you would have to render and animate the (hidden) 3rd person model as well as your first person version just to get the shadows. And preventing *that* particular shadow of your third person model from showing up on your first person model afterwards so that it does not create any annoying artifacts due to the offset would probably involve even more pain.

-WildCat-

CrushaK wrote: »

It surely can, but it would probably involve changing their rendering pipeline, otherwise we would have seen it by now, I think.

I doubt this would be a big deal to implement. Maybe I'm wrong but I get the feeling that Spark is built in such a way that these sort of changes can be done easily. A couple of weekends ago, I did some hacking around in the shader files and managed to increase the radius of the bloom effect as well as make the atmospherics render at 1:1 resolution with no blurring. The performance impact of the latter of those two changes was brutal but the point is that I was able to achieve moderate success without really even knowing what I was doing so I'll bet this would be trivial for an experienced programmer.

CrushaK wrote: »

Or the reason is performance savings, since you would have to render and animate the (hidden) 3rd person model as well as your first person version just to get the shadows.

Perhaps... but there can be a lot of models and geometry on screen and this is only 1 more.

CrushaK wrote: »

And preventing *that* particular shadow of your third person model from showing up on your first person model afterwards so that it does not create any annoying artifacts due to the offset would probably involve even more pain.

That's an interesting point and one that had not occurred to me. I like the idea of my own head casting a shadow onto my gun but, indeed, it would be a problem if the third person gun cast a shadow onto the first person gun. I wonder how Quake 4 got it right.

CrushaK

There are different approaches to a render pipeline. Each with their own drawbacks and advantages. Maybe the pipeline that was chosen for Spark is not easily capable of doing this kind of thing due to the order and number of rendering passes?

Perhaps Spark is using Deferred Shading? The transparency issues mentioned there sound quite familiar.