Entities that don't count as entities

[motorsep]

Is it possible to have entities, that don't count as entities?

 

I am sure that modern engines have a way to have all the foliage and world clutter without embedding entities into the map.

[SteveL]

We've been discussing this issue recently in Biker's "current limits" thread.

[OrbWeaver]

From the purely DarkRadiant perspective it would also be useful to have this concept, since it would allow previewing of def_attached entities (such as torch models that automatically spawn an attached light source). This wouldn't affect anything in the map though, it would just enable more realistic preview rendering in the editor.

[motorsep]

Well, you can still see inlined entities as regular entities in DR.

[motorsep]

Why not just crank up entity limit to a million ?

[161803398874989]

Do you even into memory bro?

[motorsep]

I would think we aren't in 2004 anymore.. How much RAM would 1,000,000 entity array would "eat" ?

[SteveL]

It's not just the memory taken up by the entities themselves. Functions that have to return a list of entities (like "give me a list of all entities that are touching me") often do it by using a fixed-size list that has enough room to list all entities in the map (tech note: that's so that they can do it using fast stack memory instead of slower dynamic memory). So when you increase the limit you increase the size of thousands of memory allocations per frame, not just one, And other things like the physics question "what's touching what?" have to test every entity against every other entity -- those could become a million times a million checks instead of 8k times 8k checks. In reality the game rarely does that much work of course. There are ways to optimize that kind of thing so that you don't have to do an absurd amount of work, but there's no one-size-fits-all solution for optimising algorithms, so when you drastically change the size of something like the entity limit you have to re-test and probably re-design a bunch of algorithms. It's not just a question of how much memory most players have to spare.

[motorsep]

Got it. Sounds like inlining and current limits are the only solution for variety / performance, until someone comes up with implementation of entities that are treated as geometry and nothing more.

[jaxa]

http://wiki.thedarkm....php?title=SEED ???

 

 

What is it

 

It is foremost an entity manager that can:

• Generate entities from "templates" (even multiple templates at the same time)
  
• Place created entities on random positions with random rotations (and random vertex colors)
  
• Only creates (spawns) the entities that are "near" the player (saving memory and CPU time)
  
• Removes entities "far" from the player, thus overcomes the entity limit
  
• Create entities depending on the surface of the floor (no trees on metal, or only pebbles on sand etc.), or based on an image map (greyscale image)
  
• Manage entities that were manually placed in the map
  
• Combine many entities into one rendermodel (with a matching physics object built from multiple clipmodels), speeding up drawing thousands of things on the screen at the same time dramatically (this also helps overcome the entity limit)
  
• Is tied in with the "Object detail" menu setting (so the player can control the amount of detail, depending on the speed of his machine)
  
• Works entirely automatic, but has still a lot of manual control for the mapper
  

The system also includes support for inhibitors, e.g. areas that are clear of generated entities. This way a forest clearing can be specified with only a few entities, instead of being pieced together from multiple generators.

Edited November 25, 2014 by jaxa

[OrbWeaver]

Well, you can still see inlined entities as regular entities in DR.

 

Yes, you can see inlined entities because from the DR and mapping perspective they are just regular entities that happen to have a particular spawnarg set on them that only makes a difference during the dmap process.

 

What is broken in DR is the rendering of "implied entities" that are not created explicitly by the mapper but spawned automatically at runtime based on entity definitions. For example, a "torch" entity might have a def_attach line that spawns a light at a particular location on the model, and perhaps another def_attach to spawn a smoke/flame particle system. The mapper does not see these automatic entities at all in DR, which presents a problem specifically with lights because they don't see any actual light from their torch model.

 

This is however a completely different issue than the need to create large numbers of detail objects, although they might both make use of similar code in DR if eventually implemented.

[motorsep]

I see, now I get the issue. Didn't have such case yet myself.