Improve beam rendering

[res2k]

Q2RTX currently supports beam rendering; however, it has some shortcomings:

• Quake 2 allows for beams of different widths, and "thick" beams are used for effects in several levels. The current beam rendering completely ignores the width.
• Beams are rendered as billboards. This is somewhat inferior to original Quake 2, which renders beams as actual cylinders.

To make the beams look a bit better, this pull request contains the following changes:

• Consider the requested beam width
• Change beam rendering from billboards to actual cylinders (via intersection shader)
• Reduce beam opacity near surfaces, to give a softer look

Image for comparison (using a small test map):

• Original Quake 2, GL renderer:
  
• Current Q2RTX, GL renderer:
  
• Current Q2RTX, RTX renderer:
  
• Changed Q2RTX, RTX renderer:
  

[apanteleev]

This is a good contribution, thank you!

I just gave it a quick try and noticed one issue: the beams are missing end caps. For example, in the baseq2 security map the beams are often visible from their ends, and they look like hollow half-cylinders in that case. Can you improve that please?

Also, did you check performance? On your screenshots, there is a significant difference: 136 FPS on the old code vs. 105 FPS on the new code. But I didn't notice anything that dramatic during my test.

[res2k]

About the framerate: This large difference is due to the "current" screenshot having been made with the build from Steam (ie a Release build), while I took the "new" screenshot with a Debug build.
Anyway, I did some more tests. Interestingly, 41b711c introduced a performance regression, even without lasers - but I fixed that with af395bf. (Makes me think: perhaps LTCG might unlock a bit more performance?)
With that I did another comparison: ~144FPS with Steam release, ~143FPS with "new" release. Seems okay to me ;)

About the end caps: Sure, I can look at that.

[res2k]

End caps (end spheres, really) are now on the branch, enjoy!

[apanteleev]

As you may have noticed, version 1.5 of q2rtx has been released today, featuring ray queries. This pull request didn't quite make it into this update, but it's still a good one.

Prior to release, I've updated the PR branch to work with ray queries and with the transparency UBO changes made in r1.5; it's pushed into the beam-int-shader branch here. The main reason it's not included into 1.5 is that I observed some performance regression (13%) in ray pipeline mode with the new beams, and there was no time to dig into that.

[res2k]

Hey, thanks for providing the updated branch. I'll play around a bit, maybe I can find something wrt the performance drop.

[res2k]

So I tried to look into the performance drop.
What I found so far: the mere presence of the intersection shader in shader_stages seems to trigger the slowdown, even if the shader isn't referenced from the rt_shader_group_info, and the "beams" BLAS isn't set up.

[res2k]

An additional observation: the contents of the shader don't matter either. Just having SHADER_STAGE(QVK_MOD_PATH_TRACER_BEAM_RINT, VK_SHADER_STAGE_INTERSECTION_BIT_KHR) adds additional milliseconds to direct and indirect lighting, even if the intersection program just consists of an empty main().

As for an explanation... no idea. Blame the driver? Perhaps it's taking a different code path and/or doing something weird when an intersection shader is present?
As the new ray query mode shows, the slowdown doesn't seem to be something inherent in using & handling procedurally generated hits, or the particular "beam" logic.

Perhaps a way to deal with the issue would try to rearrange the pipelines, try to leave the intersection shader out of the pipelines that don't really use it (eg direct, indirect lighting). Maybe I give it a try, even if it'll complicate the pipeline creation & handling, and seems more like a workaround for some other issue elsewhere.

[res2k]

Hello again. I was able to "rearrange" the pipelines, exclude the intersection shader (actually, all "transparency" shaders) from the pipelines that currently don't use them - see the latest commits. Turned out it wasn't as complicated as I feared.

For me this brought the frametime onto the same level as with ray queries, so perhaps give it a spin.

FWIW, if nothing else, consider cherry-picking c63c0e3, as that replaces some magic numbers with symbolic constants.

[apanteleev]

This was a great investigation, thank you! I've made some minor changes - re-enabled the particles/sprites for the first indirect bounce, but not beams, because the particles can affect smooth specular reflections. This is merged now.