2nd Shot: Your tree looks fine, and has a good poly count. Matter of fact the tree looked like it had a few 100 polys, but MED shows otherwise. Good skinning!
3rd Shot: It seems that your particle function is only 2.0 ms, thats ok for particles. BUT, your functions are 10!!! It seems then that you are using explosion entities(the yellow spark models) with actions assigned to them, then you created a mass of them at run time. These actions are eating resources unneccisarily. This is not really a good idea since particles render faster than models. Even then, its not a good idea to use models in your explosion unless the animation is really beleivable. Using a spark sprite will render much quicker, plus the camera wont really know its a flat image because the explosion will be in a blink of an eye. If you insist on using models in an explosion ,use them sparingly, say about 2-4 models. We have to economize the effect until it becomes less of a power hungry brute. After we can get the effect down (which functions should be around 1.2ms(after you've see the explosion already, its a ram thing), and the ref as much as we can. What functions are you calling in your explosion entities? Traces? C_Moves? I dont see how the functions can hog 10 ms in the debug panel, because I dont see any other moving NPCs, or Player entities. We have to now disect almost all happenings in your game to pinpoint the problem. This functions lag may be more serious than your slow Refresh rate.
I see that your explosion is in the form of the Cross, or X if you want to call it. This is just like bomberman as you said, and these bombs are the bombs that go off almost ALL THE TIME when you play bomberman. Just looking at your explosions (even though they are pretty), the amount of particles and functions(forget about ref right now) are WAY too much, and these bombs will be going off left and right in your game. So if we are having problems with ONE explosion, we'll be in a world of hurt for MANY explosions, not to mention the vacation slide show we'll have when our computers lag during multiplayer. This could however, be an explosion used by a level trigger, or a single air strike, or a one time use super bomb. These circumstances force the use of the explosion to be very little, so it dosent matter if the lag is large, since its a special explosion. Its almost the same reason why many games have their main character to have thousands and thousands of polygons with fingers, wrinkles and eye lids, while the NPCs in which the camera dosent focus to much have a MUCH lower polycount. Thats because the player is a special character, just like a special explosion, just in this case, we want a special reason to see the spectacular lag bomb
Even though DOOM 3 runs on a high end computer, the developers are ALWAYS ALWAYS ALWAYS optimizing code/graphics to acheive the best performance with as little as possible. I think your going to have to:
1. Reduce the created particles WAY, WAY, WAY down.
2. Figure out whats going on in the explosion entities, and what they are running thats causing the 10 ms lag. I see that your explosions follow the shape of the terrain. Are you looping unnecissary traces in a while loop?
3. Create LODS for your tree models, and your sprite particles.
4. Reduce clip_far. I say that becuse it seems you will use an arena type enclosure like bomberman. You can reduce the clip_far WAY down. This will also decrease the distance at which your LODs will switch. This will cause your models to switch to their next LOD level at faster increments if the camera is moving at them. This ultimatly will bring a lower poly count since we dont draw unnecisary polygons from far away.
About the REF when you see many smoke sprites up close:
5. Do not use TGA sprites for your explosions. This may be a case where flared PCX sprites will actually look good with a black outline, since your game is cell-shaded.
6. Reduce the resolution of your sprites as much as you can. Dont worry about pixelation, because at run time with the particles moving, we wont have time to stare at the sprites. Lower resolution sprites will only look bad when you take still shots, but dont worry about it. Screenshots wont do any game justice, no matter how pretty the screenshot is. To see it in action is to see it as it truly is
7. As before, reduce the amount of particles as much as you can. If you want to keep that thick cloudy look, instead of using a single ball of smoke in a sprite, and putting these together to make a cloud, make a sprite that has many smoke balls in it, or make a cloud formation in the sprite. This will cause the thickness of the cloud to still be present, just with lesser sprites. Metal Gear Solid for the PS2 used this technique liberally during the game. For example in the beginning of the tanker level, it was raining heavily. So instead of making each rain drop a sprite and multiplying this to a thousand, the artists created a sprite that had MANY rain drops in it and used fewer sprites altogether. This is the kind of trickery we must do in games, since everything you see on your moniter is pure trickery, from the colors you see to the movies you watch. Its ONE BIG TRICK :P
8. try setting this:
d3d_entsort = 0;
"If this predefined variable (default 1) is set to 0, transparent entities are not sorted before rendering in D3D mode. This can produce visible sorting faults of transparent entities with high alpha values or alpha channels, but increases the frame rate when a lot of transparent entities are on the screen. Single polygons of transparent entities, as well as transparent particles are generally unsorted for speed reasons. Therefore they can wrongly overlap each other, which normally is not noticeable on the screen."
In our terms, it means that when d3d_entsort is ZERO, transparent entities are not sorted during runtime. That means a transparent sprite that is 100 miles away from you, will overlap a transparent sprite that is 2 feet in front of you on screen. It may look funny, and somtimes downright creepy(especially on TGA tree models), but for our cases this wont be noticable since we have a thick cloud of explosions.
I will never use the excuse of you not having a super fast computer, because this is a foolish copout. Dont worry about your system specs hindering your FPS or other stats, because I'm sure the best developers are the ones who can make great looking/running games on very shallow system specs.
We'll keep digging and fighting, tooth and nail, until we get your level to bow to your feet.
