Rangefinder HUD

[nullsystem]

Description

• In meters, the distance between the player and solid wall
• Skybox and >= 1000m will return "---m" to show infinity value
• Only shown in ADS
• ConVars:
  • neo_cl_hud_rangefinder_enabled - 1 as default, Toggle enable/disable
  • neo_cl_hud_rangefinder_pos_frac_[x/y] - 0.55 as default, position in fraction in screen width/height
• Added to settings > General to toggle rangefinder

Toolchain

• Linux GCC Distro Native Arch/GCC 14

Linked Issues

• fixes Rangefinder HUD #761

[AdamTadeusz]

I'm trying to get the rangefinder to detect the range to objects in the 3D skybox too, but the traceline goes right through some of the objects in the 3D skybox even with MASK_ALL

Nagrywanie.ekranu.2024-10-23.134707.mp4

[Rainyan]

I'm trying to get the rangefinder to detect the range to objects in the 3D skybox too, but the traceline goes right through some of the objects in the 3D skybox even with MASK_ALL

Without knowing the details, just a throwaway idea: have you tried transposing the trace to the sky camera offset (and scale!), continuing the trace from there within the 3d skybox space, probably quite similar to what the bullet penetration trace length calculations do, and then upscaling the skybox fraction by the skybox scaling factor?

Or are you saying the ray is just not hitting the desired entities at all?

[AdamTadeusz]

I'm trying to get the rangefinder to detect the range to objects in the 3D skybox too, but the traceline goes right through some of the objects in the 3D skybox even with MASK_ALL

Without knowing the details, just a throwaway idea: have you tried transposing the trace to the sky camera offset (and scale!), continuing the trace from there within the 3d skybox space, probably quite similar to what the bullet penetration trace length calculations do, and then upscaling the skybox fraction by the skybox scaling factor?

Or are you saying the ray is just not hitting the desired entities at all?

That's exactly what I'm doing, the first pic with the two traces is inside the skybox. the trace on the right succesfully hits a part of the 3D skybox, but the trace on the left goes straight through the tall dark building, hitting the mountains in the distance, hence the really big range value in the video

[AdamTadeusz]

Hitting the ground and some of the objects in the skybox works, but not for others

[Rainyan]

That's exactly what I'm doing, the first pic with the two traces is inside the skybox. the trace on the right succesfully hits a part of the 3D skybox, but the trace on the left goes straight through the tall dark building, hitting the mountains in the distance, hence the really big range value in the video

Hmm, no clue then. Perhaps decompiling the map and seeing what kind of props those are would help. (Func_illusionary? Debris flags on a prop model?) Or I guess you can also grab that info from the debugger with a trace, but decompiling to VMF might be more intuitive for debugging what exactly happens there.

Or maybe noclip into the skybox container and fire some rays manually to see if you get different results?

---

It's also quite popular to disable collisions altogether on skybox models etc. for perf (or at least perceived perf; I haven't profiled it to confirm whether it'd make a meaningful difference in typical scenarios with modern hardware), so this might be preventing the trace hits(?) As typically you would not expect anything to collide within the 3d skybox. If this is the case, I guess the simplest solution would be to just have a convention of not disabling collisions like this for the 3d skybox - although it'd be up to mappers to respect that or risk "breakage". But maybe there's some way to make the trace hit models regardless of "no collision" flags?

But I'd be perfectly content with a "fix" of to just make it a mapping convention and put the onus on the map author to not make their 3d skybox uncollideable, if we want to support rangefinding for the 3D skybox. Since all maps will eventually be recompiled for the new engine anyway, so full backwards compat for such a feature would not be critical.

[AdamTadeusz]

That's exactly what I'm doing, the first pic with the two traces is inside the skybox. the trace on the right succesfully hits a part of the 3D skybox, but the trace on the left goes straight through the tall dark building, hitting the mountains in the distance, hence the really big range value in the video

Hmm, no clue then. Perhaps decompiling the map and seeing what kind of props those are would help. (Func_illusionary? Debris flags on a prop model?) Or I guess you can also grab that info from the debugger with a trace, but decompiling to VMF might be more intuitive for debugging what exactly happens there.

Or maybe noclip into the skybox container and fire some rays manually to see if you get different results?

It's also quite popular to disable collisions altogether on skybox models etc. for perf (or at least perceived perf; I haven't profiled it to confirm whether it'd make a meaningful difference in typical scenarios with modern hardware), so this might be preventing the trace hits(?) As typically you would not expect anything to collide within the 3d skybox. If this is the case, I guess the simplest solution would be to just have a convention of not disabling collisions like this for the 3d skybox - although it'd be up to mappers to respect that or risk "breakage". But maybe there's some way to make the trace hit models regardless of "no collision" flags?

But I'd be perfectly content with a "fix" of to just make it a mapping convention and put the onus on the map author to not make their 3d skybox uncollideable, if we want to support rangefinding for the 3D skybox. Since all maps will eventually be recompiled for the new engine anyway, so full backwards compat for such a feature would not be critical.

So the models that don't get detected by traceline are prop_static with no collision mesh far as I can tell. I guess you could change collision type to bounding box and that would give you a decent approximate without having to create collision meshes for all the skybox props, but it would require a recompilation of all maps like you suggested.

(Thank you DESTROYGIRL for helping me out with this)

There's also an interesting class in the sdk which we're not compiling right now called trace. It had functions like TestLine_DoesHitSky which seems to handle static props specifically. There's a reference to some triangles which makes me think it might actually be looking at the visual model of a static prop, but I'm not a hundred percent sure. I'll see if I can compile it and get it to work

[Rainyan]

LGTM. I noticed that the rangefinder doesn't seem to pop up when spectating other players, for example:

• Spawn some bots
• Set bot_attack 0
• Go to spectator
• Go to first person spectate of a bot
• Run bot_mimic <your_client_index>, i.e. bot_mimic 1 most likely
• Run the +aim command so the bot mimics it
• Bot zooms in with their gun, but there's no rangefinder visible when spectating them

But we could merge this if you don't want to clutter this PR.

[nullsystem]

@Rainyan Updated to also deal with first-person spectator also