Jump to content
The Dark Mod Forums

Expanding entities limit beyond 8192


motorsep

Recommended Posts

You can experiment with raising the number if you want, although it'll need a recompile of the code, so you can't raise it for a single FM. But if you're working on a separate branch of the game/engine, then you can raise it. It's a constant MAX_GENTITIES defined in gameLocal.h.

 

The fact that there's a limit at all is for performance I should think. Lots of things every frame need a list of map entities: triggers, forcefields, and movers need to know what's touching them, script events need lists of potential targets, and lots of things need a list of all current entities. The hard limit in the code means that all these temporary lists of entities can be created on the stack, instead of needing (slower) dynamic memory allocation. I can't see anything magic about the value 8192 except that it's a round number in binary. I guess that was chosen to be big enough but not too big. Every entity in the map has to think every frame (though you can optimize that a lot where you need to) so having too many will cause slowdown.

Link to comment
Share on other sites

You can stuff maps with non-interactive func_static entities to your heart's content, that's never caused problems for me.

Come the time of peril, did the ground gape, and did the dead rest unquiet 'gainst us. Our bands of iron and hammers of stone prevailed not, and some did doubt the Builder's plan. But the seals held strong, and the few did triumph, and the doubters were lain into the foundations of the new sanctum. -- Collected letters of the Smith-in-Exile, Civitas Approved

Link to comment
Share on other sites

That's right, I should have said all active entities. Func statics do contribute to physics calculations with their collision models, but they don't need to think independently. And whatever processing time they do take will no doubt scale proportionately. My main point was that having some limit, any limit, is in itself a performance optimization because it means the game can use faster memory. If you do try higher limits I'm sure we'll be interested to know what the effects are!

Link to comment
Share on other sites

That's right, I should have said all active entities. Func statics do contribute to physics calculations with their collision models, but they don't need to think independently. And whatever processing time they do take will no doubt scale proportionately. My main point was that having some limit, any limit, is in itself a performance optimization because it means the game can use faster memory. If you do try higher limits I'm sure we'll be interested to know what the effects are!

 

Try this: https://www.unigine.com/products/valley/

 

Then let me know if you can accuse those devs of being sloppy and putting too many entities on that map ;)

 

So, sure, there is a limit when engine isn't designed for such things. Thus my questions is why ents are capped at 4096 and how to quadruple entities count without breaking everything else (clearly certain things need to be adjusted to cope with increased entity count, but what exactly)

Link to comment
Share on other sites

id is famous for their limits. Devs have been knocking them down left and right for years, as well as changing designs so there are no limits at all.

 

We bumped the entity limit from 4096 to 8192 a long time ago, and I don't recall there being any large rewrites that needed to accompany that.

 

We bumped the collision limit from 2048 to 4096 as well w/o needing to do anything other than change the limit.

 

Both changes were needed to accommodate large maps with more entities.

 

I'm not familiar with Doom3 BFG, but your devs should just change the limits and see what happens. If they run into problems, then debug those problems and make the necessary changes.

Link to comment
Share on other sites

We bumped the entity limit from 4096 to 8192 a long time ago, and I don't recall there being any large rewrites that needed to accompany that.

 

That I know how to do changing GENTITYNUM_BITS 12 to GENTITYNUM_BITS 13 :)

 

We bumped the collision limit from 2048 to 4096 as well w/o needing to do anything other than change the limit.

 

How do I do that?

 

I'm not familiar with Doom3 BFG, but your devs should just change the limits and see what happens. If they run into problems, then debug those problems and make the necessary changes.

 

It's the same when it comes to entity limits. My devs only know so much about the engine. They wouldn't know where to start digging about all the entity limitations. Currently entire focus was around fixing renderer to work with AMD as well as with NVidia, porting tools back, fixing Linux port, making Blender tools, etc. Haven't really gotten to expanding engine with new capacity and new feature for gameplay.

Link to comment
Share on other sites

NB the entity limit is purely in the game, not the engine. The entity limit isn't referenced anywhere in the engine code. I'm not sure about the collision model limit as I don't know where it's defined. The TDM engine has a single global constant "LUDICROUS_INDEX" currently set to 2^16 which is uses to catch runaway loops if game limits are exceeded. Seems that number has to be at least as high as your highest game limit. Tels put a warning in a comment on MAX_GENTITIES, reminding future devs to check LUDICROUS_INDEX if they raise the entity limit.

Link to comment
Share on other sites

And what about 4096 collision models limit, does it mean that I have to turn torches or paintings nonsolid on bigger maps?

 

I'd be interested to know if anyone can answer this one. Do FS keep their separate CMs, or do they get absorbed into the world CM during dmapping? I guess they might have to keep separate ones since you can toggle them hidden.

Link to comment
Share on other sites

I'd be interested to know if anyone can answer this one. Do FS keep their separate CMs, or do they get absorbed into the world CM during dmapping? I guess they might have to keep separate ones since you can toggle them hidden.

 

If you inline func_static, the entire thing, including collisions, gets embedded into .proc/.cm and not counted as an entity.

 

"inline" parameter is broken in Doom 3 engine (although that was fixed in Quake 4). I would like to know if func_statics with "inline" can have skins and all that.

Link to comment
Share on other sites

  • 3 weeks later...

Supposedly there is no correlation between GENTITYNUM_BITS and decals/debris/etc.

 

One can keep cranking GENTITYNUM_BITS along with whatever else requires cranking (collisions). I am sure there is a limit when engine begins choking, but from what I understood after talking to ID folks, no limits decreases when increasing GENTITYNUM_BITS.

 

Can anyone confirm or disprove it?

Edited by motorsep
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...