What are current max limits for the following:

[Bikerdude]

Should I try adding the posibilty of a having particle at an idLight? I guess a few spawnargs with offset, rotation and .ptr name would be enough. If we add the same support for the other model spawnargs, then you could have a ligh with a streetlamp and a haze when on, and streetlamp and no haze when off.

yes please.

I think a mapper could do that anyway by targeting the func emitter from the light. I might be wrong.

If the light is switchable the Func_emitter isnt always turned off/on so it would be better if we could have the emitter in the light def.

[SteveL]

I've spent a few hours testing "inline" and I've come to the conclusion it's not worth fixing :-(

 

The problems:

It writes copies of the models into the proc file, so you'll add about 20kb per model to your (unzipped) proc file.

It slows down dmapping exponentially the more models you inline. 200, you won't really notice. 500, add a couple of minutes. 2000, I gave up after an hour and a quarter.

Piling lots of inlined models on top of one another (I did a pyramid of 500 barrels) causes shadow errors.

You have to add a caulk or clip brush because it will draw a FS for you without adding an entity for the model, but it won't make it solid. We could make it write the collsion model too, but that'd double the file bloat.

[Tels]

I've spent a few hours testing "inline" and I've come to the conclusion it's not worth fixing :-(

 

The problems:

It writes copies of the models into the proc file, so you'll add about 20kb per model to your (unzipped) proc file.

It slows down dmapping exponentially the more models you inline. 200, you won't really notice. 500, add a couple of minutes. 2000, I gave up after an hour and a quarter.

Piling lots of inlined models on top of one another (I did a pyramid of 500 barrels) causes shadow errors.

You have to add a caulk or clip brush because it will draw a FS for you without adding an entity for the model, but it won't make it solid. We could make it write the collsion model too, but that'd double the file bloat.

 

Oh boy.

 

So, we are back to either blindly double the entity limit and try to mitigate the effects, like always allocating a temp 16K*4 byte block and running through all entries, by keeping a "highest entity ID in use" variable.

 

In addition, more "multi entitites" or more usage of the model manager (in an automatic way) could also help.

Edited November 22, 2014 by Tels

[SteveL]

What looks best right now would be if we can assign multiple (different) models to one entity like you were speculating on above. Do any of your existing model management techniques work that way? Can we present multiple render entities or render models from a single entity, each with its own origin and orientation?

 

If so we could add a spawnarg "inert" for func_statics, and get the game to combine all "inert" statics in each visleaf into one entity.

[Tels]

What looks best right now would be if we can assign multiple (different) models to one entity like you were speculating on above. Do any of your existing model management techniques work that way? Can we present multiple render entities or render models from a single entity, each with its own origin and orientation?

 

Yes, I belive that already works in the engine. But not sure. (Techncially there is no reason why it shouldn't work. After all, the renderer doesn't care wether 1 or x models are presented by the same entity to it.

 

If so we could add a spawnarg "inert" for func_statics, and get the game to combine all "inert" statics in each visleaf into one entity.

 

I'm not quite sure if SEED (which would be the logical place to do that) can already do it. It can definitely combine multiple models into "1 entity+1 model".

 

Since it already contains all the logic what to combine and what not (do not cross visleaf, keep the distance, same type and so on), it should technically be able to do that. I'm just unsure if the path "1 entity + multiple models" is implemented. If not, I think it would be quite easy, back then we didn't have the engine source, but now the sky is the limit

 

(I know I already implemented "multiple emitters per one entity" so multiple particles (which are just "fany models" anyway) works.

 

Edit: SEED is the class that handles "multiple models, multiple entities", the ModelManager is the low-level class that cobines multiple rendermodels into one.

 

Technically, to combine multiple func_statics, you draw a SEED entity in DR and then link the func_statics as targets to it. But I think we could automate it, spawn a SEED entity, and add targets to it. Of course, care must be taken that the targets of SEED don't need to spawn. But it could work.

Edited November 22, 2014 by Tels

[Tels]

After looking through the code, SEED combines entitie's rendermodels after they have been spawned. So it's not usable right away due to:

1. combining the rendermodel (this would actually work for func_statics, but might stutter if they have LOD stages)
   
2. only doing so after-spawn.
   

We need to build a multi-model entity (this probably needs a new entity class) and add the rendermodels to it for each entity that we don't want to spawn.

 

Edit: A bit more info:

 

CStaticMulti is the class that contains one rendermodel and multiple clipmodels. Back then I could combine rendermodels, but not clipmodels. But I think the performance is better with multiple clipmodels due to each of them having a small idBounds instead one large.

 

Anyway, this class can easily be extended to have multiple rendermodles, I think. In the worst case we might have to use the ModelManager and add the visible models of func_statics together to one rendermodel.

 

The challange is to do this before spawning the entities - SEED currently kicks in after all have been spawned.

 

The "SEED can overcome the entity limit" is based on the generation of entities, where we don't spawn the entities but instead generate from procedural and image-map rules.

Edited November 22, 2014 by Tels

[Moonbo]

This is more of a one off short term solution than the high-level fixes everyone else is talking about, but I did notice that you can add the model spawnarg to most entities such as trigger relays, func_remove, path_wait, etc. By giving them a model you can combine their function with one of your func_statics, thus reducing your entity count.

 

Of course the downside to this is that these entities become much harder to spot in DR so I would only do this at the very end of the mapping process (if it's worth doing at all).

[motorsep]

I've spent a few hours testing "inline" and I've come to the conclusion it's not worth fixing :-(

 

The problems:

It writes copies of the models into the proc file, so you'll add about 20kb per model to your (unzipped) proc file.

It slows down dmapping exponentially the more models you inline. 200, you won't really notice. 500, add a couple of minutes. 2000, I gave up after an hour and a quarter.

Piling lots of inlined models on top of one another (I did a pyramid of 500 barrels) causes shadow errors.

You have to add a caulk or clip brush because it will draw a FS for you without adding an entity for the model, but it won't make it solid. We could make it write the collsion model too, but that'd double the file bloat.

 

Not sure about TDM engine, but having models in .proc files reduced memory usage and increases map loading time for us. Map compiling slowed down a bit. Although I haven't tested it fully with that many entities. Can you upload your test map somewhere (with all appropriate assets, so I could just plug it in and run it) ?

[motorsep]

We need to build a multi-model entity (this probably needs a new entity class) and add the rendermodels to it for each entity that we don't want to spawn.

 

Isn't it something I recently inquired about in a separate thread?

[SteveL]

Although we do want to try intelligent methods of combining FSs, inlining might help with urgent entity limit problems after all.

 

I rejected it above because it made dmap take hours and caused shadow errors. It does always make dmap take longer (you're generating much more worldspawn surfaces after all), but it turns out that the really nasty dmap times only hit you if you inline more than 200 or so entities in the same visleaf. The process slows down exponentially the more stuff you inline in a single visleaf. It depends on the complexity of the models that you are inlining, but inlining 30k polys per visleaf doesn't seem to cause much slowdown.

 

I tried my thousand-barrel test a couple more times. With all 1000 barrels in the same visleaf, it looked like it wanted to take hours again. With VPs placed between each group of 200 barrels (though still in the same big room), it took just a couple of minutes. Also the shadow errors only seemed to kick in when I had lots of barrels piled up. In this map, where they are separated, it was glitch-free. (VPs are in red by the way):

 

 

I did make the test as nasty as possible. All 3 lights hit all 1000 barrels, and they are all shadowcasting so there was max work being done on writing shadow volumes to the proc file (which ended up at 20mb).

 

One disadvantage of inlining is the only way to make a model non-shadowcasting would be to amend the material file. And if you need a model to be solid, you'd need to put a clip brush over it. But it could be useful for saving a bunch of entities in indoor rooms, especially ones that don't need a clipmodel. That would even be good for performance: you save a clipmodel each time and save collision tests every frame.

 

I should probably commit the tiny fix to svn so it's there for use if someone wants to use it. The inlining code is already working in the engine. All the fix does is stop the entity from spawning if it's been inlined (current behaviour is to spawn it but hide it, which is pointless). Only 2 existing maps have any "inline" spawargs, and they are for just 4 or 6 unnamed inert func_statics (ceiling beams and shelf brackets). Nothing will change for those maps except they have 4 or 6 fewer entity count.

[Bikerdude]

• But it turns out that the really nasty dmap times only hit you if you inline more than 200 or so entities in the same visleaf.
  
• Only 2 existing maps have any "inline" spawargs, and they are for just 4 or 6 unnamed inert func_statics (ceiling beams and shelf brackets). Nothing will change for those maps except they have 4 or 6 fewer entity count.
  

• Funny you should say that, when I split my 250 bottle FS into 5x 50 FS models, I also found the DMAP times went back to normal.
  
• Right, if I have a bunch of FS in a leaf I could apply the inline arg to them? For exmple those wine bottle models in the cellar, and can I assume inlinging would reduce the entity count at map time..?
  

[SteveL]

• Funny you should say that, when I split my 250 bottle FS into 5x 50 FS models, I also found the DMAP times went back to normal.
  
• Right, if I have a bunch of FS in a leaf I could apply the inline arg to them? For exmple those wine bottle models in the cellar, and can I assume inlinging would reduce the entity count at map time..?
  

• It seems a lot of dmap techniques do a check-everything-against-everything-else routine, so if you double the number of something you end up with 4x or 16x times the work. Visportals seem a good complexity reducer and a lot of the calculations happen within one leaf only.
  
• Yes. My entity count in the map with 1k inlined barrels was 11. The barrels were 0 entities. I'll commit the (tiny) fix now, just finished testing the last compile. Please do it one visleaf at a time at first and try the map so you can check for shadow and long dmap-time problems.
  

You'll be able to undo it again at any point by doing a find/replace on "inline" "1" in the map file, or by selecting all entities and adding "inline" "0". So it's reversible at any time, as long as you haven't already added a load more entities

[SteveL]

Committed. Not sure if you spotted it above before it got buried in conversation but I added a "countEntities" command you can use to test it.

[Bikerdude]

I'll start using this in ernest once 2.03 is out, thanks for doing this mister.