Product Chat / In Game Metrics - One for the Experts or Lee perhaps - or Not?

Author
Message
Uman
GameGuru TGC Backer
19
Years of Service
User Offline
Joined: 22nd Oct 2004
Location:
Posted: 12th Feb 2014 17:59 Edited at: 12th Feb 2014 18:02
Please see attached screen shot : In Game Metrics.



Anyone - user or not in a position to understand and explain something of this regarding the Metrics : Polygons, Draw Calls and FPS Readouts? Perhaps Lee or someone else from TGC can clarify this hopefully if no one else is able to do so?



The Screen shot shows two separate screen grabs from different locations in the same level - basically different sides pasted on into the other so we have different Metrics Readouts display.



You can see roughly the complexity at each screen shot location.



1. Why are the Polys and Draw Calls metrics displays bars always seemingly maxed out or thereabouts no matter what the engine is displaying even in an empty level with flat terrain and nothing else at all in the level? Just start flat level and run - same maxed out bar displays for Polys and Draw Calls. Why would this be?



2. Why are they Polys and Draw Calls bars "Particularly the numbers displayed as the bars are always full" shown in the two variations apparently at illogical odds?



"In the screen shot with More/much higher numbers of Polygons and Draw Calls being recorded - why is it that More Polygons and Draw Calls result in a readout of almost Double the fps speeds when anyone would expect the opposite to be the case"?



With More Polygons and Draw Calls being displayed we are seeing improved performance and fps by an factor of almost two and doubled?



That's the logical reverse of what it should be surely.



The more you have here in view being displayed the better the performance by a doubling effect of fps apparently?



I am sure there's a rational explanation - I just don't understand what it is? Am I missing something obviously that I just don't understand here?



3. No screen shot for this. Why is it in editor at start if you select new Flat Auto Generated Terrain the object limit indicator is already well over half way full and opening the level you see in the screen shot above where there is quite a lot more detailed terrain and all of the added objects to consider it does not push it up much more?



Does this indicate that by using and starting level building with nothing but a Flat Terrain it already counts the Terrain as eating and consumes over half the available number of objects the engine counts and will allow?



Presumably so?



The Flat Terrain apparently then is not counted as one object but many? or you would only get to add half another single object?



How many objects does this limit specify internally?



What is the number?



********



DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 12th Feb 2014 20:43
The performance bar has been bugged since it was introduced. I think I mentioned it at the start of my bugs and bonuses video. Once it goes up it never seems tr come down, no matter where you look.

From your pictures, it looks like you have more types of entities in the left picture, compared to the right. That would increase the draw calls, even though it is on a more empty looking scene. Each object you load will add a draw call for each texture it has. I did an AGK video ages ago about draw calls and keeping up speed, if you want to see how they work in tests. Basically, each image /texture you load will add a draw call. You can speed up a program by keeping the amount of images down to minimum, by using the same image for many objects. Say you did a UV map of a object but for some reason had a bit of space left on it you couldn't fill. You could potentially use that space for another object that only uses the corner of the image for it's UV. This would mean 2 objects use just 1 draw call.



Polygons looks a tiny bit higher on the right, which makes sense as you are right close to those trees. Also, I'm not sure if there is much or any terrain culling yet. If there is perhaps being up close to objects will help reduce the terrains huge poly count. If you press, ctr? I think it brings up wireframe, which I'm sure you know, the terrain uses a lot of polys when you look at a long flat stretch.



Yeah memory is a concern, the terrain seems to hog a lot. Obviously you have the actual program core as well, not sure how much the actual terrain takes up in comparison.



There does seem to be a lot of draw calls for those scenes though, not sure why. Perhaps it is a post processing thing multiplying them up? Not really played much with shaders so am unsure.

Login to post a reply

Server time is: 2024-05-05 09:10:34
Your offset time is: 2024-05-05 09:10:34