You may find this article http://isg.cs.tcd.ie/kavanl/papers/ppp-i3d08.pdf interesting, though it may not be the solution to your problem - it shows a very nice approach to solve a similar problem.

It is about generating 2D representations of 3D models for animating large crowds without fps loss.

There are cheaper ways to have them avoid each other and just use c_move or c_trace for the razors

Yeah, even simple vertical non oriented cube or cylinder detection is really sufficient.
And C_trace, C_move are really slow in 3DGS, if you can avoid sure you will boost a lot performance also.

Using sprites, yeah it ca be a really good option, if you can make at minimum 8 or more directions.
The problem : when you play a 3D animation, what frame the 2D animation should start ?
Also some game use only sprites rendered from 3D models , and it looks really good, parhaps you could go that way also ?

for the record, c_move and c_trace arent that slow.. you wont notice any difference unless youre tracing long distances everyframe and so on..

Yes, they are not slow. In fact they're very fast for what they do. But if you don't actually need entities bumping into each other then there are faster ways to keep them from completely overlapping each other.

Jibb

We use several tricks to speed up our zombie game where many moving entites can be seen at the screen. There are 4 things wich can eat a lot of performence:

* no LOD models: Create LOD stages if possible
* ent_animate/blend, bones, vertex: Bone animation is much slower than vertex animation. The ent_animate function is also slow, so execute it only when the enemy is not clipped!
* use a while loop for every entity: Use a big game loop to handle _every_ entity! This will also heavily speed up things! Besides that, you get a huge amount of control...
* c_move, c_trace: We use "node-cells" in our game, so we can say each moving entity if it needs c_move (movement), or c_trace (detect the floor below) because everything is set in the cell properties. If we don't need a c_move or something like that we simple change the position with vector commands...
* change entity scale: Do not change the entity scale_... values over several frames. Sprites are fine, but models will decrease the fps heavily...

There are a lot more things which can help, perhaps we can open a "performence TIPS&TRICKS" wiki-page?

Cool ideas, how do you check if the entity is not clipped if I may ask, definately would be nice to have such a wiki to crunch out the best performance of the engine

That's stunning: a single loop? I have to re-think my whole way of programming.


What are the "node-cells"? Is this a grid of rooms within the level?

BTW, thanks for your insights!

A whole loop would be Hell to manage !
Each time you want to add an entitie you would have to add it in your main loop , or remove it !
Not easy at all, and you could remove by error another.

Read again - he already DOES it. So it seems to work.

@ratchett:

Why should this be awful? You have got the global entity list and if you want to maintain own lists you could for example use a std::vector or so for this and could write an own function like entRemove that removes the pointer from the list and the global list at the same time. Kinda trivial.