Efrags?

[Baker]

DarkPlaces removed efrags rather early in DP's history. Like 2002 or so if I recall.

And I think ZQuake (the Quakeworld client) removed efrags.

efrag = entity fragment, I assume. Maybe for brush models that are part of the map like lifts or something?

Questions for anyone willing to answer:

1. What are efrags used for? Like what kind of situation?
2. Why was DarkPlaces able to remove them even in early DP history?
3. Why does a map like GLQuake still able to run a map and get the message "too many efrags." and the map still works?
4. Or ... is the map actually still working completely?

Just wondering what purpose they serve.

[Spike]

efrags are used by only static entities.
run out of them and you might have a few invisible static entities.
they affect nothing but static entities.
the map is fully functional, but you may have invisible static entities.

when the renderer walks the leafs it looks through each one for its efrag chain. each efrag indicates a static entity (which may already have been seen that frame). walk the list and you can pull out multiple per leaf. then just send those to the renderer.

DarkPlaces bruteforces static entities. It has a list of them and it checks each in turn. A bit like how the server does its pvs checks. Which method is faster depends upon the number of leafs, and how many leafs a single static entity is in.

[mh]

A static entity can be in more than one leaf. Depending on how qbsp carves your map, depending on the positioning of your static entities, and depending on how many static entities you have, it is possible to run out of efrags even in a standard (i.e. non-high-capacity) map.

Note that software Quake uses efrags for regular brush model entities as well as for static entities, so if software Quake is important to you and you're messing with efrags you'll need to take that into account.

[Baker]

Hmmmm ... I feel like I understand this slightly less than before I got answers to the question.

I guess part #2 of the question ... when is Quake creating static entities?

Static entities are ones that are never modifiable by QuakeC. So this isn't platforms. It isn't monsters.

So just func_illusionary and flame models? Or is there something else that creates them?

Some Travail maps and Forwards Compatible get the "too many efrags" message with the standard limits ...

Yes the WinQuake part of the answer MH provided does confuse me slightly but also does not concern me. I hate jacking MAX_ defines because of, well ... mostly the PSP engine with the limited RAM and don't desire to chip, chip, chip away at things affecting RAM limited systems. (But that's ok, I can give the PSP a special #ifdef clause ...)

[mh]

Anything that's sent through makestatic in QC will end up generating efrags.

If you know your RDBMS stuff, all that efrags really do is serve as the bit in the middle of a many-to-many relationship. Let's restrict discussion to static entities for now, just to keep things clearer.

A leaf can contain many static entities. This should be obvious, e.g. if two torches are right beside each other they will likely be in the same leaf.

An entity can be in more than one leaf too. Because entities have volume, the top-right-front corner of the bbox could be in leaf A whereas the bottom-left-back corner of the bbox could be in leaf B.

So what we have is a many-to-many relationship between leafs and entities. For a database you'd need a Join Table (or Junction Table) between them to manage the relationship; for Quake ID used a similar concept but called it "efrags".

In memory-constrained situations it may be helpful to know that:

• You don't actually need to store static entities in an array. You can just allocate each entity_t from Hunk memory as required and everything will work.
• With GLQuake you don't need to store efrags in an array either, and can likewise just allocate them from the Hunk as required. (The situation is a little more complex with software Quake).
• Because Hunk memory is automatically cleared between maps you don't have any risk of leaking or wasting memory.

I wrote tutorials some time ago on removing the limit for both of these items, which are available here.

Statics: viewtopic.php?t=1928
Efrags: viewtopic.php?t=1930

I still think the statics one is kinda neat, but I'd do efrags slightly differently these days. It's a good enough starting point though.