Shadowmaps for GZDoom (can be tested in QZDoom now)

[Tormentor667]

...and Randi herself...

[Graf Zahl]

I had suggested to dpJudas to check for player viewpoint proximity. People won't really notice if the light isn't culled by a pillar that like 2000 units away from the player.

Probably a good way of doing it. I just need a good easy way of taking portals into account when doing it. Maybe something like check if a portal line is in sight, then repeat the test on other side of portal as well.

All that stuff can be done in the linking step. It could flag if the light touches a portal and also if the light won't touch any blocking geometry. And then none of such flagged lights need to be checked. And of course it should traverse the blockmap in a spiraling pattern around the player, so that the closest lights are prioritized.

[ZZYZX]

Also: isn't classic shadowmapping dumb and very straightforward to implement?

Why don't you implement it then? I never signed up for that.

I think they were already implemented by Graf but never reached public.
Also I would, but IDFK how the GL renderer works at all. Workflow wise.

Also: if these lights are ONLY intended as a random visual sugar like bloom or SSAO and not as a mapping tool — ok. That's sad. I'm leaving the thread.
(and wish you good luck with your experiments though — I can understand that as a coder, but as a mapper it's a massive disappointment, sorry again...)

[Jaxxoon R]

I fail to see how this feature is incapable of being used as a tool for mapping. As a mapper, I can think of several situations where this would be an extremely handy tool, and I fully intend to make use of it.

[Graf Zahl]

Also: if these lights are ONLY intended as a random visual sugar like bloom or SSAO and not as a mapping tool — ok. That's sad. I'm leaving the thread.

What have you been smoking?
Ideally the shadowmapping should be automatic, i.e. each light is supposed to cast proper shadows.
The main issue here is that the feature isn't even fully implemented yet, so it costs too much processing time. Therefore it is disabled by default right now. It also comes with rather steep hardware requirements, i.e. OpenGL 4.3 is a must.

The bottom line is: Due to the above issues the presence of shadowmapped lighting cannot be taken for granted, it won't work on older hardware and if some user chooses to switch it off for performance it also won't have an effect.

[ZZYZX]

What have you been smoking?

I wanted to play with ray tests, then saw a simple opportunity to generalize it as a small contribution to GZDoom.

I read that as "I've been toying with yet another optional visual thing". Just like Bloom or SSAO or lens distortion — all the other things made by dpJudas that are optional and not controlled by the mapper.
Again, I don't say that these features are bad or something. They indeed benefit end users, but that's called facing one auditory and turning your back to the other.

Ideally the shadowmapping should be automatic, i.e. each light is supposed to cast proper shadows.

What if I'm trying to fake soft ambient lighting? What if I really want unrealistic lights ON PURPOSE? Sometimes I'd like even more unrealistic lights than GZDoom has — such that even stuff that faces away from the light should be lit.
This is for 3D color gradients for example — think of a candle that's bright white on top, because the light "shines through" the candle. (this effect: http://rcysl.com/wp-content/uploads/201 ... Laptop.jpg)

Disabling shadowmaps is not always a matter of performance optimizations — sometimes it's actually intended. And what I see here is that the devs are like "yay we weren't able to make shadowmaps for 20 years, now we should overcompensate it by making all lights shadowmapped".

[Graf Zahl]

Ideally the shadowmapping should be automatic, i.e. each light is supposed to cast proper shadows.

What if I'm trying to fake soft ambient lighting? What if I really want unrealistic lights ON PURPOSE? Sometimes I'd like even more unrealistic lights than GZDoom has — such that even stuff that faces away from the light should be lit.

Then you need the ability to opt out. The default should clealy be shadowmaps on here, because in 99% of all cases it's what is desired. And if all else fails, for some maps a compatibility setting may be needed.

[ZZYZX]

Then you need the ability to opt out.

Yes, and I'm completely ok with it being on by default, but the problem is that according to dpJudas' responses it's not even planned to enable/disable shadowmaps per specific lights. That's why the reaction.

[dpJudas]

Yes, and I'm completely ok with it being on by default, but the problem is that according to dpJudas' responses it's not even planned to enable/disable shadowmaps per specific lights. That's why the reaction.

I have made no such statement. If you check the forums you'll see that before it got merged in I was discussing with Graf whether it should be enabled for all light types or only of the attenuated type, with exactly the concern that it might not always be desirable. Graf replied at the time that it would be better to create an opt-out system.

That the current code doesn't implement an opt-out system is no statement about it never going to do so. What I've been saying is that I have no intention of implementing real 2D shadow maps at this time.

[Graf Zahl]

This entire discussion is dumb, because the feature is just in its early stages and needs some serious work to become usable. But to become usable it must first be made to actually be activatable, so that we can work on it - and that's where we are right now.

[Rachael]

I'm starting to feel like this discussion is headed in a bad direction, so I'm throwing the deadbolt onto it before things do get sour.

There is certainly room for improvement in the future with this feature, but they will come in due time, and certainly not by agitating and irritating the developer responsible for it. You may have your wants and desires for it, but the way the talking goes on this thread demotivates anyone from wanting to contribute further. I wouldn't be surprised if there has already been regret just by introducing it in the first place. (No good deed goes unpunished, eh?) That's really not a good thing when you are looking towards the future and want to see other enhancements like this later on down the road.

In the future - try to be more nice. And let's not forget what happened with MaxED. We don't want a repeat of that.