"sometimes i have allot of smoke in the level coming from explosions. The smoke doesn’t infect any noticeable when i am at a distance... but when i come close the time goes up allot."
This definitly happens ALOT, especially when the camera is close to the particles and theres a GREAT mass of them. You dont have to right a new explosion effect, but probobly just tweak it to be more camera friendly. Well, lets see what we can do.
An idea that came to mind is to switch between 2 slightly different particle functions. Say for instance, if the camera is close to the smoke grenade or tear canister, you can switch to a particle effect that spews out fewer particles, but particles that are larger than the original particle effect. That way the particles can cover the screen just like your original particle effect, but if fewer particles since they are much bigger:
run a code like this in your grenade action:
my.skill54=vec_dist(my.x,camera);
if(my.skill54>=1000) // if the emitter is farther than 1000,
{
effect(Far_Tear_Gas,1000,my.x,normal); // use a particle function that spews out alot of particles. Its ok because the camera is far away and not in the cloud volume//
}
else // If not farther than 1000, we use the larger sprite particle effect
{
effect(Close_Tear_Gas,100,my.x,normal); // use a particle function that uses Larger sprites and a slower emission rate //
}
The larger sprites will substitute for many smaller sprites than the original mass particle effect. Of course the ref will be affected but not as bad as the original effect function.
2. You said your game is cell-shaded, so despite your GPU handling the load, your cpu still has to draw the extra black outline polygons, which to my understanding is no different than a polygon in the original model. The polygons will still need resources to sustain themselves.
I dont know how the cell-shader will handle LODs for your model if you decide to make LOD stages. I dont know if the shader will use the first LOD model, while the main model is using a lower poly version due to distance. Make a few LOD versions of your model, each with a LARGER drop in polycount than the last one.
You can also use trusty old vec_dist to remove the material when the entity gets past a certain distance, and reapply the material when he gets close.
my.material=null; // just make sure to change the lighting after
3. What you said about Mip Maps is totally opposite to what Mip Maps really are. What you said is called a "detail map", its a tiling texture that supposedly makes the texture look more detailed (never wanted to use it). A MIP MAP however is different sizes for your texture, each in decreasing detail, which is swapped in and out in run time. So you said that your terrain size was 1024x768. If you go into MED and into the skin editor of your terrain, go to "edit", then "convert skin". Then go to "add mip-maps". Now Med will generate 3 skins in decreasing size. So the first skin you have is 2048x2048, and MED will generate these next skin sizes:
1024x1024 then,
512x512 then,
256x256
After saving and running it in WED, your terrain wont run the full 2048x2048 skin, but use the smaller mip maps for the parts of the terrain that is farthest from the camera. What this does is ease up the burden off the cpu, which would normally draw the texture full at 2048x2048, but now is drawing it at smaller sizes, which should free up the refresh stat. Plus it gets rid of contrsted noise from complicated textures that are far from the camera, since they are blurred.
