Author: {wf}shadowspawn <shadowspawn_at_shadowspawn.net>     Reply to Message
Date: 4/9/2004 11:46:18 AM
Subject: RE: wtf

Yes the client creates temporary entities based on events, or sent entity states.

the lens flare refractions are it's own array that have their own state client side once they are sent the actual entity state from the server. Server sends bigflare ent, it's specifics to the client; client recieves it and then ignores it for the remainder of the map (I gotta fix the vid_restart flush tho, make it sorta persistant in memory), sets some values in the client game array, during the main screen function it checks for it's presence (after a cvar check) and if it's there it runs through the normal display/population routine. The array of sub-flares share the same stuff that the main cg. array holds so its technically one client-game semi-persistent array.

Particles do the same thing, they are their own deal once spawned by either an Effect flag (engine entity state) or Render flag (render state), or by an Event. Each particle is run in it's own routine eventually, each particle has it's time to live.

beams are sorta handled the same way because they can last for more then 2 frames. If it's just one frame it's actually not even visible; which I gotta fix to make it act like q3's ET_ Beam.

Each has it's own reference to the renderer, the renderer handles each array as an entity and just reads off flags to push through the main renderer module and mesh module. This way the engine can push a crapload of polies and not wait for any particular entity to finish up; once it's gone in the client there's no loop to check for it's existence. It just always has a count of what to render and doesn't go above or below that.

It's one of the reasons you can just keep on piling stuff into the engine without affecting GPU performance, but client-side (engine) VIS/PVS before rendering is an expensive math operation so the more ents, the more vis checks.
_