SamVanheer
commented
3 years ago I checked this again to see what, if anything is going on here.
The test map i used is broken because the room the camera is in is outside the normal grid range (4096 units from origin). The camera origin is being clamped causing it to end up in the void, which causes the glitchy rendering behavior. This map was made using a level editor designed to work with engines that increase the maximum grid range, which masked the true cause of the issue when i initially tested it.
As far as other maps go i haven't found any that have the issue. All references to this issue date back to the WON days so it's possible that this was a bug in SDK 1.0 era games and mods, fixed when the code for view entities and view rendering was moved to the SDK in SDK 2.0.
CL_EmitEntities works as intended, the code i was referring to is used by HLTV spectators.
The client correctly overrides the player's view position here: https://github.com/ValveSoftware/halflife/blob/c7240b965743a53a29491dd49320c88eecf6257b/cl_dll/view.cpp#L815-L828
All evidence points to this bug having been fixed a long time ago, however it's possible that the bug only occurs under specific circumstances that are not easily replicated. I'd recommend keeping this issue open in case anybody else encounters it so they can provide a test map to reproduce it with.
Using trigger_camera outside your PVS causes visual issues. The world is not rendered, and other entities will either be drawn completely black or do not appear. Since the screen is not cleared, the previous frame will remain and cause repetition of older frames.
I've done some digging and found one possible cause. In the engine's CL_EmitEntities function, ei.simorg is used. The code in question is used to calculate the leaf in which the client currently is.
simorg is the client's absolute position in the world. trigger_camera uses enginefuncs_t::pfnSetView to set the current view entity, whose origin is tracked in several locations. In refdef calculations, it's vieworg. In the renderer, it's r_origin.
I think that if this function were updated to use vieworg, it would work.
However, the client currently overwrites vieworg in refdef calculations, setting it to simorg before doing anything else. This will probably need an update as well to work.
Since this code resides in the client library, this change will likely require a cvar or liblist.gam option to control it, defaulting to off to prevent issues.