[FTE]Load / refresh level performance question

[toneddu2000]

Hi insideqc engine gurus! I'm here with a question and not an issue, this time. It's been a while (1 year I guess) since I don't use radiant + q3map2 anymore (yeeah!), infact every level I do it's made directly in FTE and I'm pretty happy with it. Now, since I'm creating a game with several levels (like every other game in the planet, I guess), I'd like to know if this could lead to performance problem.

I explain myself: when engine starts, my only-csqc game loads an empty bsp map, with just 6 black walls, a light and an info_player_start entity. Anyone of these elements is mandatory: a closing hull structure is needed otherwise FTE realtime lights won't work (you can't just create a plane and uncheck "Stop on leak" flag in NetRadiant: it will compile but it won't see rtlights in FTE anyway), a light with targetname(even with radius set to 1 it's ok) is needed to stop FTE to print the "No lights" warning at startup and info_player_start is needed because otherwise NetRadiant won't compile.

So fa so good. Now I created an entity which represents the level and a float that represents level current. When CSQC starts hull.bsp, it spawns level entity and setmodel first "map object" model onto it. When "Load new level" command is triggered somehow, I simply change new map object model to level entity, reset flags that needs to be restarted and that's it.

This leads to the question: This continous swap level models (with relative possibly huge textures attached) without any restarting (for restarting I mean the canonical way to issue the "map foo" command) could lead to performance issue? The continuous loading new models and textures replaces old ones or it keeps filling memory space?

Should I use the map approach or the engine will do the memory free by yourself when that model is no longer tied to any entity?

Thanks in advance for any suggestion, I'm pretty sure this conversation could lead to interesting solutions/opinions and different point of views!

[Spike]

the renderer and rtlights code ideally wants pvs. this requires a model on the world entity..

rtlights should be set us as static world lights in order for their shadowmesh cache to work. recreating them every frame is NOT a good solution - which is what will happen, as only the worldmodel's surfaces can be cached in the shadowmesh. Large submodels are NOT good for performance as a result - the shadowmesh will instead need to be regenerated every frame.

a pure csqc mod can use the disconnect command occasionally to purge the qc state (and transient data like lightmap textures and unneeded models), but if you want to purge everything then an occasional vid_reload will unload all the models unused or otherwise. they can still be poked, but do note that this can result in stalls as vid_reload is a little lazy. altrnatively try the flush command.

[toneddu2000]

[frag.machine]

You may avoid some of the problems a huge submodel creates by breaking it in smaller, modular sections (this also opens the possibility of artwork reuse). But the engine will always ressents the lack of PVS data that allows to prevent unseen stuff to be rendered. I believe FTE (like every other Quake engine under the sun) assumes submodels always change position or angle and thus light info must be recreated every frame, killing the performance. The bigger the submodel, the greater the hit.

EDIT: in SSQC you can use the parm1 to parm15 cvars to store info between maps.

[Spike]

the worldmodel must be .bsp (true pvs) or .map/terrain (distance culling). don't bother trying iqm.

dynamiclightadd allocates a dynamic light (or reuses an existing one).
static lights start at 32, which is messy. and you'd need to scan for new ones or something. which is ugly. and override ALL settings, which sucks too. you might also be able to get away with makestatic. not sure if I remembered to code that for static lights in csqc, but its a bit more limited.

lots of small submodels suck too. there's a tradeoff here. try to stick to 1ish texture per submodel, if possible.

vid_restart tears down everything, including the entire rendering context and window.
vid_reload destroys models+textures+shaders, but doesn't obliterate the rendering context itself. this avoids video mode switches or the desktop appearing, or other programs getting input focus, etc. its much less jarring.
flush flushes the models+sounds, and reloads them when they're next poked. doesn't destroy anything that would require any internal pointers to change - sadly this includes textures.

iirc, my purecsqc mod was lame and just used a cvar to carry info from one map to the next. resetting the entire game was also a simpler way to flush all the ents and static ents/sounds. that said I did initially have a version that just directly swapped the map over (as well as precaching it during intermission for pretty much instant map changes).

[toneddu2000]

[frag.machine]

I think he means FTE starts with a 32 positions array to store static lights, and this can be expanded later if required, but probably with some performance penalty.

EDIT: regarding cvars you can use between levels, there is also scratch1 to scratch4, and if I am not mistaken FTE allows you to create your own cvars via QC (at least SSQC), although I never used it.

[toneddu2000]

[frag.machine]

[toneddu2000]

ok, thanks anyway frag.machine

[Spike]

[toneddu2000]

So ****** awesome! HUGE thanks Spike!
I wasn't even aware of all those LFIELD_

Funny thing is that I don't see any difference on performance with just one light. Probably it takes 2 or more lights to see performance diff. And, I must say, I used LOTS of shaders in this project, so, probably it's better to start with a fresh new project for better benchmarks

I tried to change LFIELD_FLAGS from LFLAG_REALTIMEMODE to LFLAG_NORMALMODE and LFLAG_LIGHTMAP but no effect, I guess lightmap is only in "get" mode and not set.

Anyway super cool function Spike, thanks a lot!

[toneddu2000]

[frag.machine]

parm1...parm9 are used in single player to pass player info across levels (health, ammo, armor, weapons, etc). Check client.qc and you'll see in DecodeLevelParms ().