Question for dpJudas; future screen shader plans?

[Nash]

For the longest time, I've abused ACS and HudMessages to do fake screen effects. These of course "look" cool at first but are obviously clunky and limited. Now that the shader pipeline is in GZDoom, I was wondering if you have plans to add any of these effects natively into GZDoom?

For clarification, this is NOT a request thread. I'm just asking out of curiosity. For each any of these that will not go into GZDoom, I will most probably do the work required to implement them into my game (inevitably pestering dpJudas every now and then for source code help, I'm afraid ) and share the changes in my game's source fork (which has already been publically available on GitHub since the beginning). That said, if any of these get into the renderer, then the entire community can benefit from it of course.

1) Lens flares

2) Coronas (I *think* that's what they're called; those 7 little auxiliary flares that accompany the main glare... ZDoomGL and Doomsday has those)

3) Camera dirt (Doom 2016 has these; it looks like an altered bloom pass because wherever the dirt appears on the screen is also exactly where the overbright parts are)

4) Water droplets (my ACS version just uses cheap animated sprites; I was hoping the shader implementation to actually distort the screen with refraction? So each "drip" will subtly distort the view. Perhaps as a generic GZDoom effect, it could be done so that when the player is submerged underwater, the screen warps and distorts like in Quake 1, then immediately after surfacing out of the deep water, a short animation of the droplets "dripping" down the player's helmet will play)

5) Film grain/noise (just an animated HudMessage; I just flip through 4 fullscreen noise graphics and paste the animation on top of the entire view, with semi-translucency)

6) Vignette (again, just a fullscreen graphic pasted on top of the entire screen as a HudMessage)

Thanks for your time.

[dpJudas]

What my plans are? Now that is complicated to answer. Before I started working on (g)zdoom I had been coding on my own 3D engine for a long time. The initial bloom and tonemap passes were more or less a port of passes I already had. The way I did the render buffer stuff was also based completely on that work, which was part of the reason I knew exactly how to plug such a system into gzdoom.

When I did my truecolor renderer I did not even know gzdoom existed and the only real reason I was playing Doom at all was because some personal events had caused me to more or less give up on my own engine. That was partly due to the common idea amongst most hobby gamedevs of late that Unity is the only way to write a game anno 2016, and partly due to just not having any real assets for my engine. The sad truth about 3D engines is that if your textures and models look awful, then nobody gives a shit about the thing rendering it.

Anyhow, to try make this short, what I realized when reading the zdoom projects forum is that there's almost an endless ocean of assets connected to Doom's modding community. My motivation for coding on gzdoom was initially to fix the software mode light and the windowed mode. But now my motivation is more driven by its usefulness as a place to write and test shaders. The SSAO pass is my second attempt at such a pass, where the first one I did in my own engine never quite worked. My personal objectives for the SSAO branch are "done" in the sense that the shader is working and ready to be moved home to my own engine. I'm only really finishing that branch because I think it looks nice in gzdoom as well.

So to answer your question about the types of effects you are referring to there, yes, I am interested in writing all of those passes. But when it comes to gzdoom it gets a little bit complicated because any solution kind of has to be done properly, and most of those passes involve linking up assets/textures to the pass. I know virtually nothing about that part of the codebase, how it is best used with ACS, and so on. What all this means is that I might consider some stuff too tricky to do in gzdoom compared to solving the same problem directly in my own engine.

Not sure any of this made you any wiser, but there you have it.

[Nash]

Interesting and 100% understandable with regards to your original motivation... and 100% clear answer as far as these new passes in GZDoom goes. Totally get what you mean as to the HOWs and modder scriptability, etc. The actual implementation details. To be honest, I haven't a clue right now either but my philosophy is; when actual work is done and something is half-working, the ideas will come spontaneously. :P

There's always modders like me around should you need feedback on how a GZDoom-context implementation should best be tackled, so at least you know there's people to ask opinions from.

Anyway, thanks for the reply. There's no rush implied here, and for anything that won't make it; as I said, I'll probably find a way, somehow. :P

[Rachael]

That was partly due to the common idea amongst most hobby gamedevs of late that Unity is the only way to write a game anno 2016, and partly due to just not having any real assets for my engine. The sad truth about 3D engines is that if your textures and models look awful, then nobody gives a shit about the thing rendering it.

The work you've done on GZDoom is a real résumé. Any company that turns you down now is making the most horrible business decision of the year.

Nevertheless, I think the new additions are awesome. I could say so much more, but it all really just comes down to that.

[dpJudas]

Thanks Eruanna. I'm sure there's plenty of companies that would hire me, but the hard part for me is getting a job that pays well, has an interesting challenge, and at the same time has *nothing* to do with web. Not so easy in Denmark.

[Rachael]

Yeah, I hear you. I hope you find something that suits you.

[ibm5155]

"has an interesting challenge" - That's going to be hard for your type, but since you like 3D stuff, what about making some 3D engine for fulldome theaters?. (at least on my university there's a high demand for fulldome software).

I'm almost in that dilema, I like to break software and also code using C and also making terminal like apps, but there's almost zero companies that work with that here, almost all of them Works with web or java uhhh (and I belive no one likes terminal apps nowadays :X).
I still remember that on my last job I needed to make an database with excel because the company was so closed that it would only allow you to use vba and excel for everything

[Nash]

hey dpJudas, not sure if you already saw - but someone went ahead and added lens flares. I figured it would be beneficial to have another shader expert have a look at it and perhaps provide technical feedback. :D https://github.com/coelckers/gzdoom/pull/244

[Graf Zahl]

Thanks Eruanna. I'm sure there's plenty of companies that would hire me, but the hard part for me is getting a job that pays well, has an interesting challenge, and at the same time has *nothing* to do with web. Not so easy in Denmark.

Tell me about it. I've been looking for something new and fresh for the last 2 months now, but programming jobs are exceedingly hard to find, and most offers are so mired in buzzword technologies that I'd rather pass. Chances are that the hiring company won't be here in 5 years anymore.

Oh, and most employers want an university degree in informatics, no matter what - too bad that at the time when I was studying those things were not really available.

[dpJudas]

Luckily in Denmark the lack of a degree is not completely an obstacle for getting a job. But it still means you have to suddenly justify why you think you're qualified without one. And the more attractive the job, the bigger a disadvantage it becomes.

@Nash: I'm a sucker for all shaders, useless or not. This shader obviously could still need some work visually, but more importantly I think such a feature should be more directly linked to dynamic lights. I see that kind of shader more as an enhancer for corona light flares - its purpose being to add a little more chaos/complexity to the scene so you don't notice that the real light flare is made out of sprites. Kind of like the lens distortion is about breaking up straight lines.

There's also the catch that mixing photorealistic lens flares with low resolution textures and low poly map geometry will probably not look too good, as Graf pointed out on the ZDoom forum. On the other hand, a map custom made with attenuated point lights, new textures and some 3D models scattered around the scene might benefit nicely from it.

[Nash]

!00% agree on the aesthetical dissonance when applying cinematic effects against pixelated images; and also agree that at the hands of artists and custom artwork and 3D models, it could be a very useful tool to enhance the visual experience.

I strongly think that at least the 2D corona sprites would fit the Doom aesthetics though - modders have already been doing these for several years (I think even Knee Deep in ZDoom has these effects) except the coronas are in world space - therefore clipping into the level geometry, which ruins the effect. But otherwise, IMO they look pretty fitting even with the pixelated Doom monsters and walls.

[Rachael]

Coronas should remain in world space, in my opinion - but should be rendered in a special way.

If anyone remembers the UT99 engine (or technically, Unreal 1, really), it did them rather well, I think. I think we could take the lessons from that and apply them similarly. It's a cheap effect, and I think in the end it will be received well, especially if you give the player the option to disable them.

[Graf Zahl]

Coronas in world space tend to look ridiculous, they should not be clipped by map geometry. If the light source is visible they should be drawn fully, if the light source is not visible they should not be drawn at all. The light source's size should be defined in GLDEFS.

[Rachael]

Ugh, okay, words fail me.

Essentially what I meant was, they should be drawn in their proper position but such a way that they are not resized by distance (they remain a constant size), dim by distance rather than shrink, and as you said are not clipped by world geometry.

Now if you'll excuse me, I have engrish I must lern.