Modeldef option to always render model

[Bauul]

Currently the rendering of in-game models is directly tied to the rendering of the underlying Thing a model is tied to, specifically whether or not the sector the Thing's origin is in is being rendered at the time.

This works fine for sprites, but in the era of increasingly large models (such as entire levels being exported as OBJs) there can be situations where you want the model to be visible even if the source-sector is out of sight.

The only current solution is the RenderRadius variable, which checks all sectors in a given radius and displays the model if any of those sectors are visible. However, in order to have a very large model consistently displayed throughout a map the required RenderRadius can end up being huge, and as it's a per-tic operation can absolutely wreck FPS on larger maps. I've had it halve frame rate by trying to get a large model to render properly (such as the staircase in Water 3 of Elementalism), meaning you have to choose between the model popping into view, or a terrible frame rate.

A long-term solution would be to render the model when any part of it would be visible, but I suspect that would be a substantial effort. In the mean time, a functional alternative would be a Modeldef flag that tells GZDoom to simply always render the model, regardless of what sectors are visible.

This would be significantly faster than using a giant RenderRadius (as it wouldn't need thousands of sight-checks every tic) and would also prevent any kind of popping-into-view that plagues using large models generally. It would be inefficient to use on smaller models placed multiple times, but for giant singular models that are visible throughout a map it would be incredibly useful.

[Major Cooke]

EDIT: Nevermind, I thought it was something else.

[Enjay]

Indeed, but Bauul's post explains why he feels RenderRadius isn't always suitable. I don't know if he's correct or not, but he's looking for an alternative to RenderRadius.

[Major Cooke]

I'm honestly wondering if this would be better as an actor flag so we can control it live instead of just a model flag.

[Bauul]

True, an actor flag would also work perfectly well too (given RenderRadius is an Actor flag there's precedent there).

[Apeirogon]

I'm honestly wondering if this would be better as an actor flag so we can control it live instead of just a model flag.

IIRC some nice features wasnt been added to actor class because of an impact on its size. Like, actors size in memory size is already several megabytes, again IIRC, which is not couples well with nowadays CPUs. So it better to be a model flag only.
"How change it than?" You shouldnt? Just redefine same model under different name with different rendering flags in modeldef. Having a list of models that ALWAYS should be drawn, no matter what is better in my opinion, that nobody asked for.