A refresh rate jump?

Would a jump in refresh rates in your level indicate a bad block somewhere?

I have an area in my level where my fps drops from 50fps to about 37 fps. Debug shows an increase in time for refresh - see the screen shots below. You can tell from the image I have only moved the camera slightly between the two screen captures and most other statistics have stayed the same (number of polygons etc).

Would this indicate a bad block?...because I have been backing out many changes and messing around - but can not figure out what is causing the drop. Please help. Any direction for debugging this appreciated.

I have something similar and much more severe than that. 8.1 is 5 times better than what I've had. I've noticed that, in my case, it gets to 41 milliseconds. I cannot explain this myself. It happens when the camera gets into a certain position. Just a change of about 40 quants, refresh time goes from around 8 milliseconds to 40. Go back down about 40 quants and it returns to 8.... I'm baffled over it myself.

PS nice scene.

Well glad to know I am not alone (I think). Wish I understood this better...don't know if I am wasting my time trying to debug nothing. I am rechecking all the blocks to see if they are snapped. After that, if the problem persists - I am out of ideas.

PS. Congrats on finishing your beta. Saw your Showcase post. I'll check it out over Christmas holidays.

Ah, I'm referring to the "pan" value in my 3D game which gets to 43. In my abandoned project, I do recall it getting clear up to, even beyond 180 milliseconds with a pyramid-like structure of blocks. When I press the up arrow, for example, there'd be quite a long delay before anything responds. Perhaps I could try to rebuild my structure so you can see the results yourself (and perhaps make it more extreme).

Screenshot - this is with the 6.22 engine as this screenshot was taken on Sep 6, 2004, 15 months ago.

Don't go to any troubl Uli. I was just hoping for some information to understand this better and hopefully save some time - as I have been getting a little frustrated ... but there probably is no short cut. Thanks anyway.

The only clues that I have is that this seems to happen when you are close to a group of otherwise small blocks crowded close to each other, possibly intersecting.

This screenshot showing this same bunch of blocks from in WED. I just recently had to open up the old project just to see it and get this screenshot as otherwise, I have no screenshots on hand of it.

Edit: it's that pyramid that you see there that's where I'm getting the extremely high ref value.

Hey Uli
Just FYI - I did find some bad blocks, which I had unfortunately copied and pasted in a few spots. I rebuilt those blocks and the problem is now gone. I should have known - because I was having some problems with shadows in a few spots and sure enough - that is where I found the bad block.

Well, I only thought I fixed this. I improved fps in general - but I can still get this problem. After spending all morning isolating and testing entities I now understand a little better what is happening in my level.

The trees and bushes are models - but the branches are 2d planes. If I put one of these trees or bushes in a level by themselves and aim the camera straight at them the refresh times are really high. If you scale these models to a larger size - the refresh time increases what looks like proportionally. So even though these models are low polys - they demand a longer refresh time. (I am guessing it is because some of these planes are viewed edgewise).

Having said that, I don't know why they behave as well as they do in the larger level - because I have lots of these bushes and trees but its only sometimes, at some angle, that these models will drive up the refresh time.

In the shot above - I believe the culprit is the tree on the upper LHS of the screen shot - which is scaled quite large. When I removed it from the scene - I had a more difficult time reproducing the higher refresh time. However because of the pink flowered bush in the foreground (also scaled larger)- I can still get the same results standing in certain spots and viewing the scene from certain angles.

The effects on fps are significant but may well just be the price of having bushes and trees...and still I am getting reasonable fps...so I think I will just have to accept that there probably is no way to optimise this other than to be careful about the scale as it does exaggerate the problem.

It could also be the problem that many engines have with showing many sprites behind other sprites. Since your sprites seem to have a "keyed" out color, or a color that shows totally transparent, the engine has to redraw many sprites in conjunction with the other transparent sprites behind it. When I say transparent I mean by sprites that have an overlay flag on to show certain parts of the image. So when alot of these sprites/models are behind each other or bunched up, the engine has to iterate through each one, redrawing it, then redrawing whats behind it, I think this is called overdraw. And I might be wrong about this, but due to this overdraw problem, that statue with its many polygons may actually render faster than 2 large sprites that are overlapping each other in the current POV.

And I think your right, I dont think there is too much you can do about this overdraw problem, because many engines have this problem. I havent made a good growth filled level with lush plants and bushes, but I thought about using a smaller scaled version of an LOD system for plants. When a plant reaches a certain distance from the camera, it would morph into its next LOD level, but the resolution of the next LOD would be greatly smaller compared to the last one. I havent tried this out, and I dont know if it would be faster to have many low-res sprites together compared to many high-res sprites together to prevent overdraw.

That's good information. Thanks jumpman. In the shot with the problem, there are about four of these trees/bushes lined up along the LHS. I will check to see if/how much of the problem may be due to overlapping..but I think I can reproduce it with just the flowered bush in the foreground. (but I guess there would be significant overlapping even with just one bush with the way these models are designed). I'll check it out.

I haven't done anything to the models yet except add mipmaps to the skins.

Ive also generally seen refresh rate jumps when sprites are close to the camera, just like the foreground bush you mentioned. It dosent even have to be a million particle effect, and could definitly be recreated with a few sprites. If you can "break" the camera and go into free look, I bet you can get better refresh rates when you bring the camera far away from the whole plant scene yet keeping all the plants in the view. Its the same number of visible plants, yet the refresh rate is better the farther away you are from them. I think the overdraw idea is in effect here too.

Dare I suggest this, because its alot of work but

Maybe you can make extremly low poly models of the plants when they are close to the camera. So that pink flower plant in front of the camera in your screenshots would morph into a low-poly "high detail" model. However this model cant have any transparent areas with overlay, and probobly a smaller skin resolution. Maybe this model would bypass the overdraw problem because it has no transparent areas for the engine to reiterate, and imo is generally much better looking than seeing a flat billboard of a plant that stares at the player when he rotates.

Though be assured this problem is tricky to resolve, and you really cant skimp out and cut corners. Getting a scene to look awsome in a screenshot is easy, but getting the scene to flow in realtime without hiccups in FPS is another monster.

Thanks again Jumpman,

I have already noticed the effects you are describing in terms of the plants behaving at a distance. I mentioned earlier that I didn't understand why they behaved as well as they did - and I believe it is because of what you are describing above. Most of the time the plants are not in the foreground.

I will have to give some thoughts to the solution. One simple thing is not to allow such a bush at a corner (thus allowing the player to get behind it and look through it) as is the case now in the above screen shot. This may solve the refresh problem. However it will not fix the 'flat billboard' problem - which can only be fixed the way you suggested.

I will have to experiment...more time. I don't know how anyone gets to end of job on these games.

Did you try the ffp or shader from vantilator that Loopix use for his plants and trees?

I think that Loopix placed it for download on his homepage.

I was trying to avoid shaders because I was concerned about how they would look or be supported on older graphic cards. I am trying to keep this game compatible with older cards. Am I being reasonable regarding the "No shader" specification?

Some older cards don't support shaders. However, every card that works with A6 can do ffp (fixed function pipeline) effects.

I had that bug too
look at this:

its the alpha channel
some graphic cards have problems with alphatextures
especially the ones you get with a new PC.

Well now that I understand the problem more, I at least have a starting point for dealing with it. I haven't looked at ffp - so I will check it out as well.
I have been gradually improving my fps but have not eliminated the refresh problem. So I will just keep trucking here to see what I can do about it.

I still haven't looked at the ffp solution yet (Loopix' site is not available at the moment) but here are some things I learned so far in trying to manage fps using a lot of models and sprites with overlay on.

1. Sprites aren't an issue as they do not overlap so much as do models like the az_bush available with the A6 downloads.

2. The biggest factor in driving the refresh time for models is skin size. The refresh time for my test bush model reduced by 50% when I reduced the skin size from 512x512 to 256x256.

3. The second biggest factor is scale - the larger the model the higher the refresh rate. But a model with a 256x256 size skin scaled to 2x it's original size still does not put as much demand on refresh times as the same model with a 512x512 skin at the original size.

4. If you skin the 2d branches with a fuller image (ie a branch with lots of leaves and flowers) you can reduce the number of branches required to make the bush or tree look full. This is the 3rd factor - doesn't make a dramatic difference.

Still working on this ... but thought I would share what I have learned (at least for my card and configuration) so far.

Edit:
Between cleaning up some bad blocks, reducing the polygons by redesigning a few things, reducing skin sizes on the bushes, and reducing some branches....
I have recovered my 50 fps. (It had dropped down to below 30 fps for some pov).

Code:

---

 
function mtl_vegetation_init
{
 vec_set(mtl.emissive_blue,mat_model.emissive_blue);
 vec_set(mtl.ambient_blue,mat_model.ambient_blue);
 vec_set(mtl.diffuse_blue,mat_model.diffuse_blue);
 vec_set(mtl.specular_blue,mat_model.specular_blue);
 mtl.power=mat_model.power;
 mtl.albedo=mat_model.albedo;
 //mtl.skill1=pixel_for_vec(vector(188,0,0),0,8888); // the first value in the vector is the threshold
 mtl.skill1=pixel_for_vec(vector(40,0,0),0,8888); // the first value in the vector is the threshold
}

material mtl_vegetation
{
 event=mtl_vegetation_init;
 effect=
 "
 texture entSkin1;
 dword mtlSkill1;
 technique vegetation
 {
  pass p0
  {
   Texture[0]=<entSkin1>;
   ZWriteEnable=true;
   Zenable = true;
   AlphaBlendEnable=false;
   AlphaTestEnable=True;
   AlphaRef=<mtlSkill1>;
   AlphaFunc=Greater;

   CullMode=CCW; // CCW or None
 
   ColorArg1[0]=Texture;
   ColorOp[0]=Modulate2x;
   ColorArg2[0]=Diffuse;
  }
 }
 technique fallback{pass p0{}}
 ";
} 

---

my.material = mtl_vegetation;

This will solve your sorting problems. If you want alpha blending change - AlphaBlendEnable = True;

Wow! Thanks William. Can't wait to try it out. (Little busy playing Santa at the moment but hope to get to it soon.). Merry Christmas.

William - got a chance to try out the code and it did have a positive effect but I am having a hard time measuring how much of an effect because I did a naughty change management thing and also updated my driver at the same time.

I am finding an increase in refresh time for all models (regardless of whether overlay/transparency is being used or not) after the driver update. LOL. So I now have to run some scenarios to reset my baseline with the new driver. But I have be able to show a positive improvement with your material definition.

Thanks again for your help.

After I updated to the 6.4 public beta I get such a jump too.
My Level usualy runs with a refresh by 0,7 but somtimes it jumps up to over 230.

Here are two pics of my level:



Has got someone of you an idea were the problem is?

I am going to guess that whatever entity is completely filling the screen in the last shot has alpha transparency on? Is there a reason for that camera to be there? It is an odd shot.

My terrain has no alpha transparency on.
The cam is turned to the ground because that´s the position where I got most times this high refresh rate.

Sorry I have not clue. If my refresh jumped that high my pc would blow up.

The letters and numbers on your debug panel look as if you had anti-aliasing enabled. Maybe this has something to do with it?

I found another thing that effects refresh times for my configuration is tga skins. TGA skins seem to put a higher demand on refresh times than say a pcx skin with overlay.

it is YOUR graphic card man
a whole cards have problems with ALPHA CHANNELS like TGA textures
its not a 3DGS fault. the problem is your graphic card.

I am not claiming it is 3dgs' fault. Do any of my posts sound like I am saying it is 3dgs' fault?

I am trying to optimise for lower end cards. So every little bit helps. And the problem is just less of a problem without tga textures. And some of the others posters indicate having seen the same problem - so the information is for those interested.