Closed WatIsDeze closed 1 year ago
The logic to adjust the gun position is in CL_AdjustGunPosition()
. It's using some hardcoded "gun dimensions", though, which are probably not quite suitable in this case (and possibly others as well).
It may look superficially simple to fix - just adjust the hardcoded "gun dimensions", right? - however, this may make other weapons look bad (being wall offset without appearing close to a wall). Not sure what the best approach would be. Maybe using the view model bbox could give satisfactory results.
It's been long ago since I did OpenGL API stuff but I recall in those days there was a solution related to depth testing, which would prevent minor issues such as this one.
Actually peeking around a bit, Q2RTX its GL renderer responds to the RF_DEPTHHACK flag. However there is zero results of finding any records of this flag being checked for in the VKPT code.
Found in shared.h
#define RF_DEPTHHACK 16 // for view weapon Z crunching
Found in client/entities.c
gun.flags = RF_MINLIGHT | RF_DEPTHHACK | RF_WEAPONMODEL;
Responded to/in/by GL_DrawAliasModel
using 'glDepthRange'.
The RTX renderer works differently, it doesn't have a depth hack equivalent. But even if it would have, it probably would result in looking weird in cases where the hack would kick in: The view weapon is actually properly located in the world, so reflections, lighting etc look reasonably right. Now, cases where the depthhack would be in effect, the view weapon would be inside a wall or such - resulting in unexpected lighting and reflections, probably looking quite off. So moving the whole gun makes sense, at least for the RTX renderer.
res2k is correct (as usual) - the RTX renderer cannot use the depth hack because it doesn't render the scene in multiple passes. The gun exists in the world just like anything else. We can, however, do a different hack here (also used in Portal RTX) - scale the gun down so that it's tiny and close to the camera, but its footprint on the screen stays the same. Then it likely won't intersect with world geometry.
Sounds like the most decent proposing solution. Any chance of seeing that actually being implemented?
scale the gun down so that it's tiny and close to the camera
Hm, but couldn't there be cases where this could look off? Say, parts of the gun would be shadowed by something in "real size", but it would either be completely shadowed, or not at all, with a tiny gun. Or is that something that's not typically noticed? Or maybe the downsizing trick is only used when it's close to a wall (like the position shifting right now)?
(FWIW, I think the weapon shifting actually makes some sense in the world - I always think my avatar is actually deliberately moving the weapon a bit farther back when close to a wall, instead of, say, just ramming the gun into it...)
Hm, but couldn't there be cases where this could look off? Say, parts of the gun would be shadowed by something in "real size", but it would either be completely shadowed, or not at all, with a tiny gun. Or is that something that's not typically noticed?
It's not noticeable unless you look for it, in my experience.
Or maybe the downsizing trick is only used when it's close to a wall (like the position shifting right now)?
Now that would certainly be noticeable. :)
Being pretty much illiterate at Vulkan (although I understand the general concept's bits here and there), I'm hoping someone can implement this. Main motivating reason would be, (new future)mods, and consistency in general of supporting a as of yet unsupported RenderFlag.
I'd have gladly done so myself if I could. Rooting for this lol.
Hi @res2k , @WatIsDeze - I made a PR that adjusts the gun scale, https://github.com/NVIDIA/Q2RTX/pull/319
It's not perfect - you can see the gun slightly shifting on screen when the scale is changed, but I think that's good enough. Please review.
Excuse me for being late to the party. The problem seems to be resolved now in all of the specific scenarios that I ran into. Seems good to me.
For example, in the current crouched position at the start of base1/demo1. Simply just having the weapon being 'offset' by game code, won't always cut it. Minor issue, and yes, occurs only if you try really hard. Possibly easy to fix?
(The game code for offsetting the weapon doesn't take the weapon animation into consideration, hence, this happens.)