PDA

View Full Version : Serious unexplainable Performance Differences - got proof



Helmut_AUT
Jun 9 2009, 19:15
Okay, this gets to the point where I really have to believe the engine has code problems or design problems. I can't explain it any other way, and I would really appreciate if we can hear from the devs here.

Using a GF9600GT, everthing to low except textures (normal) and shadows (normal), VD 1200, Fillrate 100% at 1920x1200.

Now, the test:

On the small island in Utres, walk to the first wooden house in Strelka, the first on the right as you come up from the beach.

Drop your gun.

Walk up to the house facing NW and place yourself directly in front of a stretch of wooden wall with NO windows or anything in it. With your nose touching the house, so the house blocks everthing else, straight on.

Gives me 24 FPS.

Now, I move to the opposite side of the house, walk up to a bare stretch of wood wall, and do the same.

34 FPS.

That's a 40% frame difference. Looking at the SAME texture from the SAME distance with nothing else on the screen.

I really can only explain this by assuming that they are not properly culling background objects as they get blocked by other things. Because when you are looking SE at the house, behind it is mostly open ocean. When you are staring NW "trough the house" you are looking at the destroyed church.

I have no way to take apart the engine and know what BIS has done here, but I do know that 40% framerate difference looking at the same texture should not happen. Can someone throw this on the bugtracker please?

ECH
Jun 9 2009, 19:35
Your post would go a long way in helping explain your situation if your provided pics. What you need is:
-fraps (http://www.fraps.com/) which will allow you to either record it or screen shot the situation
-programs like Media Show Espresso (http://www.cyberlink.com/products/mediashow-espresso/overview_en_US.html) allows you to convert videos to youtube
-Youtube (http://www.youtube.com/) will allow you to upload any video you created
-Image Shack (http://www.imageshack.us/transload.php) will allow you to upload your screenshots and show them to the community


I say this because what you posted is interesting and hopefully more information is addressed and perhaps fixed.

Helmut_AUT
Jun 9 2009, 20:08
I have all that, but I don't have the time right now to prepare such a detailed report.

And anyway, the gist of it is simple: If the player is in front of an object with a simple texture that totally blocks his view, the framerate varies by 40%, seemingly dependent on what is BEHIND that object. Which makes no sense because if you are looking at the broad side of a house, nothing else should be rendered at all, so anything that is BEHIND the house shouldn't matter.

Or, in other words: Looking at the same piece of texture in game, so that it fills your screen, can give you 40% framerate difference. This makes no sense since it's the same graphical detail being rendered.

dale0404
Jun 9 2009, 21:14
Ok you are onto something here. I did exactly what you said mate and here are the results. You can see the framerate in the top right of the pictures.

First picture is facing NW towards the church:

http://img15.imageshack.us/img15/5924/arma22009060923090151.jpg

The second picture is facing SE towards the sea from the other side of the house:

http://img15.imageshack.us/img15/8512/arma22009060923084864.jpg

So as you can there is certainly some performance drop!

Helmut_AUT
Jun 9 2009, 21:33
60% difference rendering the same piece of texture. Insane.

Steinfisch
Jun 9 2009, 22:34
The framerate does not only depend on the texture. The engine cannot always render all objects of a scene. This would result in a framerate under 1. So it must calculate which objects are completely outside the view frustum (the 3d space the player can see) which partially outside and which inside. This calculation leads to different results depending of your direction of sight. The more objects you can see, the slower the rendering.

Helmut_AUT
Jun 9 2009, 22:41
Steinfisch, I know that. In this case, you can only see one object, both times.

Steinfisch
Jun 9 2009, 22:49
...But the graphics engine don't know what you know. There can be different ways to calculate, and mistakes.

POTS
Jun 10 2009, 00:20
...But the graphics engine don't know what you know. There can be different ways to calculate, and mistakes.

Thats exactly what they are trying to point out, massive problem with the graphics engine. This clearly displays that people are NOT getting the performance they should with the same amount of detail.

---------- Post added at 12:20 AM ---------- Previous post was at 12:15 AM ----------

This is called overdraw right? So this would mean that the graphics engine isn't properly communicating with the graphics cards. Therefor the graphics cards processing depth that you cant see. Which ultimately means that once again, BIS has not optimized correctly for the graphics cards.

Leopardi
Jun 10 2009, 00:25
Nice find. This could bring a nice fps boost if it was optimized correctly.

POTS
Jun 10 2009, 00:28
Nice find. This could bring a nice fps boost if it was optimized correctly.

Yes, this could mean that looking at a forest or town might not kill your fps as much as it used too. Although dont expect them to 100% clear it up, just as much as possible.

-=seany=-
Jun 10 2009, 00:33
The fact that you are conducting this test next to the ocean might indicate that it is not a problem with the engine. If the same thing happens with a building in a town, in the middle of the island then it might be a problem.

The reason I say this is because you are freeing up both the GPU and CPU by looking toward the ocean, there is absolutely nothing else to render. I'm not sure that buildings and the like would "occlude" the CPU's rendering of the landscape/objects, like it would if it was outside your field of view (eg facing toward the water), or the same way a GPU occludes object's rendering and effects.

POTS
Jun 10 2009, 00:45
The fact that you are conducting this test next to the ocean might indicate that it is not a problem with the engine. If the same thing happens with a building in a town, in the middle of the island then it might be a problem.

The reason I say this is because you are freeing up both the GPU and CPU by looking toward the ocean, there is absolutely nothing else to render. I'm not sure that buildings and the like would "occlude" the CPU's rendering of the landscape/objects, like it would if it was outside your field of view (eg facing toward the water), or the same way a GPU occludes object's rendering and effects.

The problem with that is there are not any CPU variables in that situation besides the character itself, the wind, the ocean moving, and maby some animals, but I dont think those would drasticaly affect FPS like that.

Maddmatt
Jun 10 2009, 01:35
It might be because the game cannot cull terrain. Terrain is different to objects.

Meek
Jun 10 2009, 01:40
Typically games (especially FPSes) do a check to determine what objects the player is able to see before drawing anything, the benefit of this is that stuff that has no affect on the final image doesn't have to be drawn.

However, this checking isn't done for free, depending on the method used, CPU usage may take a hit, usually this is offset by not having to process things the player can't see.

ArmA2 is an exception, since the game takes place pretty much entirely outside with an extremely long draw distance, it is less computationally expensive to assume the player can see everything, although, I think terrain blocks unseen objects from being drawn, but terrain is substantially cheaper to process (terrain is a heightmap).

Although the developers could prevent unseen objects being rendered, it would decrease performance in most situations.

FraG_AU
Jun 10 2009, 02:21
The engine obviously has a long way to go in optimisations. Another test, I look through the forrest and spin I, get say 30 fps.. I look at the floor and get 30fps, i look at the sky and get 30fps.. Its like I am limited to 30fps no matter what I do. Clearly there are engine problems, and hopefully BIS is working hard to correct them. Unfortunately I am sure BIS does not have the resources at their disposal that a big studio has so will have to be patient. But you never know!

POTS
Jun 10 2009, 04:17
Typically games (especially FPSes) do a check to determine what objects the player is able to see before drawing anything, the benefit of this is that stuff that has no affect on the final image doesn't have to be drawn.

However, this checking isn't done for free, depending on the method used, CPU usage may take a hit, usually this is offset by not having to process things the player can't see.

ArmA2 is an exception, since the game takes place pretty much entirely outside with an extremely long draw distance, it is less computationally expensive to assume the player can see everything, although, I think terrain blocks unseen objects from being drawn, but terrain is substantially cheaper to process (terrain is a heightmap).

Although the developers could prevent unseen objects being rendered, it would decrease performance in most situations.

But doesnt the GPU get put under even more stress? I think what you say would only apply if we were still playing with 2.0ghz p4's. 3.2ghz dual core with large bandwidth would not be that affected by it. Were not talking about cracking sha1 here. Its just counting objects and giving out a block signal. I mean, the CPU is counting them anyway so it doesn't really matter.

Defunkt
Jun 10 2009, 07:58
What Meek said.

An algorithm (i.e. for culling unseen geometry) that yields the best result in the majority of cases will hardly ever yield a perfect result in any case. You can't draw any conclusion from this test.

POTS
Jun 10 2009, 08:09
What Meek said.

An algorithm (i.e. for culling unseen geometry) that yields the best result in the majority of cases will hardly ever yield a perfect result in any case. You can't draw any conclusion from this test.

So you have the balls to say that losing 15 of your frames looking at the same texture isn't conclusive? I'm sorry, but it just doesn't make sense. I would not care about 2 or 5 frames, but 15! Its just too much. Not to mention this is repeatable, not some random event. Something like this is worthy of more investigation and fixing.

I'm sorry, but if the obtained variables are honest, then the extreme fps loss has been concluded. Its just time to solve the next problem, what exactly is causing it and how to fix it.

Helmut_AUT
Jun 10 2009, 08:27
This is called overdraw right? So this would mean that the graphics engine isn't properly communicating with the graphics cards. Therefor the graphics cards processing depth that you cant see. Which ultimately means that once again, BIS has not optimized correctly for the graphics cards.

Exactly. That explains IMHO why inside villages, our framerates tank.

Because as I understand it, the closer you get to an object, the more detail is rendered for that object (higher LOD textures, more shading....) As the workload increases when you get close to an object, the objects BEHIND that one would vanish into "can't see", so the card can balance it's power more toward the one house you actually can see.

Right now it seems the card has to render the house you can see, and still keeps drawing stuff that is behind it.

Another thing I tried yesterday: In the barracks at Utes, I stood behind an outer wall facing the field behind it, and then moved sideways two steps so I could actually see the field and trees. Result: Field & Trees in view are 30FPS, two steps to the side (which pretty much leaves same field and trees in your view) but with the wall now blocking the scene, I get 40.

So trees, stones, terrain seems to be culled alright. But tried it the other way round - looking INTO the barracks, and then side-stepped to bring the wall into my field of view - little to no improvement.

Very rough assumption: They are not culling house or buildings correctly.

---------- Post added at 08:27 AM ---------- Previous post was at 08:26 AM ----------


I'm not sure that buildings and the like would "occlude" the CPU's rendering of the landscape/objects, like it would if it was outside your field of view (eg facing toward the water), or the same way a GPU occludes object's rendering and effects.

But that's the point: Buildings and the like SHOULD occlude the GPU (not CPU) rendering of landscape and objects.


BTW, as Frag points out, there's another explanation: Even looking at sky or ground never really gets you max FPS, which contradicts pretty much every other 3d game I ever played. Which would mean the card is not only rendering what you look at, but maybe the shading and post processing are always there, always applied to an image even if there's nothing to see and no motion.

Defunct, go ahead and test this with other houses and objects. It seems pretty universal to me.

POTS
Jun 10 2009, 09:04
It would be interesting to test this with different cards. Lets not let this go unnoticed to BIS. If we can get grass, trees, and buildings to be blocked then we've solved a lot right there. A 25-50% increase in performance for those situations should be a good target imo.

rowdied
Jun 10 2009, 09:34
The engine obviously has a long way to go in optimisations. Another test, I look through the forrest and spin I, get say 30 fps.. I look at the floor and get 30fps, i look at the sky and get 30fps.. Its like I am limited to 30fps no matter what I do. Clearly there are engine problems, and hopefully BIS is working hard to correct them. Unfortunately I am sure BIS does not have the resources at their disposal that a big studio has so will have to be patient. But you never know!

I don't have this problem. I can look at the ground 30fps, spin between 30-40fps and at the sky up to 70fps. Not to be an ass but maybe your hardware is the limiting factor? I have it on 2 similar but different systems and both show a discrepancy in fps when looking those ways.

system 1
q9550 @<hidden> 3.4
2 g 1066 ram
winxp 32bit
gtx 260 192sp 896 ram
raptor 140g hd
giga ud3p mb

system 2
q6600 @<hidden> 3.2
2 g 800 ram
8800gt 1g ram
winxp 32bit
asus p5k deluxe

both use latest 186 drivers.



BTW, as Frag points out, there's another explanation: Even looking at sky or ground never really gets you max FPS, which contradicts pretty much every other 3d game I ever played. Which would mean the card is not only rendering what you look at, but maybe the shading and post processing are always there, always applied to an image even if there's nothing to see and no motion.

What is the max fps? In the menu 60-65fps and in game hovering around 35-40fps. Not being an ass but I'm curious what that would be?
I do agree that the game needs to be optimized alot more but sometimes dream what the game could be like if they did have the budget of a big studio, say Take2 and GTA IV...
Ahhh dreams...
I can live with the bugs now because I know that the coming patches and tools will certainly transform this to be the epic game most will come to love.

Helmut_AUT
Jun 10 2009, 09:38
Max FPS should be close to vsynch or above. In most every 3d game I ever saw, looking straight down or up will give you that framerate. Even for you, the ground obviously requires a lot more rendering power than if there is nothing (the sky) in view. Why is that, it's merely a bit of shaded texture?

In other terms, you spinning inside a forest full of trees gives you the same FPS as looking static at a piece of flat texture. Doesn't make much sense, does it?

Speaking in more general terms, which is arguable not very scientific: I always had the impression that in A1 - and now in A2 - the amount of graphics quality rendered in view does not correlate correctly to framerate, when compared with other 3d intense games. Bringing up my favorite STALKER:CS example, I can set there a view distance of 500m, lots of grass and shader details, and then move trough a village full of individual buildings, partially destructed, every object casting a correct shadow on itself and others. Every spar and blank of a destroyed roof will render it's shadow on the building inside too. That's an awful lot of shading and details. But the game runs nicely at steady 30+ FPS with 2xFSAA and high details on everthing.

A similar "tense" scene in A1 or A2, even if there's less individual houses, less detailed shading and low graphic detail - gives me 20 FPS.

But the overall "feel" and detail of the scene are not that different. In fact both games can be pretty comparable since they use Russian style small villages with fences, grass, clutter. I know A2 supports a lot more view distance, but you can turn STALKER up and A2 down until they match. And you still get 50%+ more FPS in STALKER.

I'm not trying to argue that a tactical "open world" game like A2 should have the same insane graphics performance as a shooter like STALKER. These are different concepts, different engines. But both games can render pretty awesome scenery, only one is 50% faster. Which brings me back to my assumption that A1 and A2 are doing additional rendering work - maybe in the full-screen post processing - that is a total bottleneck and slows framerate even when you are looking at pretty much nothing.

whisper
Jun 10 2009, 09:58
So you have the balls to say that losing 15 of your frames looking at the same texture isn't conclusive? I'm sorry, but it just doesn't make sense. I would not care about 2 or 5 frames, but 15! Its just too much. Not to mention this is repeatable, not some random event. Something like this is worthy of more investigation and fixing.

I'm sorry, but if the obtained variables are honest, then the extreme fps loss has been concluded. Its just time to solve the next problem, what exactly is causing it and how to fix it.

That's not what he said. He pointed that, even if it's bad, occlusion culling on such a large scale engine/area may be even worse in result, or maybe it's simply huge occlusion culling calculation which explains this difference.

It may not be good, but there may be no workaround

IronTrooper
Jun 10 2009, 10:05
Helmut_AUT:
About your first post.
How can the engine know you are just looking in the wall made of continuous polygons??
What if there was a small hole right bellow or above that wall which would allow you to see other objects behind it?? The engine would have to do lots of calculations to figure that out and that would mean more stress to cpu (even though less to gpu). It renders most of objects in front of you all the time to avoid visual bugs.
I say leave the optimization to devs, you're hardly going to find something they don't know already about.

Helmut_AUT
Jun 10 2009, 10:16
Trooper, the wall is not made of continuous polygons. That is a single large flat house wall (likely a flat polygon with a texture), not a fence with holes in it. There's no question that such an object blocks view 100%.

So you are happy if the engine renders "most objects in front of you all the time" even if that means a crappy framerate? Why then, tell me, can other games do graphics as good with 50% more FPS?

Maybe because they are not rendering stuff you can't see, could that be it? Oh, and you forgot to explain why looking at the ground on a stretch of road (absolutly NOTHING in your view then, not even a blade of grass) doesn't significantly push framerate.

And no, until we hear from the devs about the next patches I'm certainly not going to shut up and pretend there's nothing to report. I have a rig that is well within the recommended specifications (not minimum - recommended specs...), I think can expect a game that gets playable framerate, and not 15 FPS slowdowns even at low detail settings with a handfull of soldiers around.

If that sounds harsh, then because it's frustrating that they created a most excellent game (core system, AI, editor, functionality) but slapped an engine on top that makes it painfull to actually play it.

Steinfisch
Jun 10 2009, 10:51
They not only have to draw the scene every frame. The physics, the scripts and KI calculations also depend on the units which are inside the view frustum, if they are friendly or not. If you change the view direction your sight of enemies change too and this leads to a range of actions. I don't know if they update these things every frame, but it has influence.

Make a little test: build a mission (editor) with only you as actor and no scripts. Add this textured object above and test the framerate. This would give a more realistic impression on what the graphic engine performs and what are other influences.

dvolk
Jun 10 2009, 10:57
You won't spend much time looking at walls in the game, so what does it matter how high FPS go when you do?

BIS could modify their algorithms to get you 1000fps when you're looking at a wall, but if it dropped overall performance by 1fps, it wouldn't be worth it.

Helmut_AUT
Jun 10 2009, 11:01
Steinfisch, my initial post already states that this is an empty editor map with only the player on it.

---------- Post added at 11:01 AM ---------- Previous post was at 10:58 AM ----------


You won't spend much time looking at walls in the game, so what does it matter how high FPS go when you do?

BIS could modify their algorithms to get you 1000fps when you're looking at a wall, but if it dropped overall performance by 1fps, it wouldn't be worth it.

When you are moving into a village (where performance drops massivley) you will by definition often move along a wall or between houses. If houses block the rendering of objects behind them then that would offset the increased performance cost for the higher LOD on the stuff you actually CAN see. Right now, as you get closer to buildings, their increased LOD adds rendering strain, but the decreased object count in your view doesn't offset this.

Sorry, but this is a very relevant test. As is the "look at the earth" test, since such things can be used to see how much object density in player view actually influence FPS.

Steinfisch
Jun 10 2009, 11:13
Of course you are right. They could optimize their code.

Helmut_AUT
Jun 10 2009, 11:29
Maybe the reason for not culling objects out of view is indeed that it would slow down the CPU too much, in which case I get why they keep objects rendered.

Wouldn't it be sweet if the 1.02 patch brings FSAA and a 20% performance increase? Arma's 1.09 patch gave some people 40%.

IronTrooper
Jun 10 2009, 11:41
I guess they could optimize this a little but as dvolk pointed out, it wouldn't really matter as you don't look right into walls or ground most of the time.

Helmut_AUT
Jun 10 2009, 12:29
Is the concept really that hard to grasp? If you are inside a town or village, you are looking towards walls ALL of the time. Not towards ONE specific wall, but you are basically encircled by walls, and if the engine renders stuff behind those walls it's absolutely pointless for gameplay, bad for performance.

And if the engine always renders an overhead even when NOTHING is in your view (ground-look) then that matters EVERYWHERE on the map.

Are you guys really not seeing the purpose behind those tests, or are you purposely obtuse since you feel you need to defend BIS Honor or somefink? Please explain to me why other games do this kind of culling, improve framerate considerable, but Arma2 somehow shouldn't?

dale0404
Jun 10 2009, 12:34
Gents, lets not turn this into a slanging match please.

People have their own opinions and ideas about the graphics engine.

What I would ask is to post some testing results that you have done yourself. Lets hope that BIS are taking notice of what we have discovered here.

SANGEKi
Jun 10 2009, 12:38
Maybe the reason for not culling objects out of view is indeed that it would slow down the CPU too much, in which case I get why they keep objects rendered.

Wouldn't it be sweet if the 1.02 patch brings FSAA and a 20% performance increase? Arma's 1.09 patch gave some people 40%.

The game is not that CPU bound anyway.
There is hardly a real world difference in performance between a Core 2 Quad at 3GHz and a Core i7 at 4.2GHZ.

Even a moderately complex culling algorithm won't slow the game down much or at all.

Even if it would make the game slower on slower CPUs it wouldn't matter because no one who owns the GPU(s) required to run this game with acceptable performance on high settings is still on a Pentium 4.

The devs (as dedicated as they might be) don't have the money/time and/or knowledge necessary to really (if even still possible) optimize the engine, let alone create a new one.
While I'm sure that future patches will indeed improve performance, it will never run GREAT.



Gents, lets not turn this into a slanging match please.

People have their own opinions and ideas about the graphics engine.

What I would ask is to post some testing results that you have done yourself. Lets hope that BIS are taking notice of what we have discovered here.

Thing is that this is not about opinions.
The engine is doing a lot more work than necessary.
This game is slightly more complex than your regular AAA shooter no doubt but most of that complexity has it's place in the CPU.
This problem here, at it's core, is a different matter.

Helmut_AUT
Jun 10 2009, 12:52
Sorry, didn't want to "raise my voice" here, and don't want a flame war, but it would be nice if people didn't respond with "you're not gonna look at a wall" type of postings, since I think other and I have already explained in detail what these tests are supposed to show.

Sangeki, I have an AMD 5000+, and the Warfare mission on Chenarus throws me to 16FPS, which are CPU limited. I can't agree that the game isn't CPU bound, and the 5000+ is actually above recommended specs.

SANGEKi
Jun 10 2009, 12:55
No, the game is obviously more CPU bound than "normal" games.
That comes with the territory of having so much possible viewing distance and AI but my comment was only in relation to the required GPU performance and the question if a culling algorithm would possibly slow the game down to much.

This is not FSX where GPU power just stops making any difference at some point and it's only CPU, CPU, CPU.

Leopardi
Jun 10 2009, 12:58
The engine obviously has a long way to go in optimisations. Another test, I look through the forrest and spin I, get say 30 fps.. I look at the floor and get 30fps, i look at the sky and get 30fps.. Its like I am limited to 30fps no matter what I do. Clearly there are engine problems, and hopefully BIS is working hard to correct them. Unfortunately I am sure BIS does not have the resources at their disposal that a big studio has so will have to be patient. But you never know!

thats called cpu bottleneck which it seems you have.

DMarkwick
Jun 10 2009, 13:05
It's most likely to be related to transparency code. There's the possibility that the wall might have a transparent texture on it, like a window, and so the engine needs to know what's behind it.

Helmut_AUT
Jun 10 2009, 13:21
I will check that, but as far as I know that house has no "see trough" windows.

FraG_AU
Jun 10 2009, 13:41
I don't have this problem. I can look at the ground 30fps, spin between 30-40fps and at the sky up to 70fps. Not to be an ass but maybe your hardware is the limiting factor?
I hope not, at the moment I would say I have a state of the art PC. While I know that each game is created differently, and each engine works differently I would expect this game to perform better then it does currently. My system is

i7 @<hidden> 4.2Ghz
6Gb RAM 1600
GTX295 OC'ed
Xfi Xtreme Gamer Fatality ed.. Ie pretty much the best system money can buy (aside from going quad sli). I never had expecations of running at 100FPS etc, but I was hoping to run more then 30-35 FPS @<hidden> 1920x1200. My ArmaMark II score is approx 4400-4700 on my detail setting, but in game it just suffers a breakdown.


thats called cpu bottleneck which it seems you have.

If I have a CPU bottleneck I pitty 99% of other users.. Sys specs as above.

Don't get me wrong I appreciate the game, the size etc, but clearly there are plenty of optimisations that need to be done to the engine aside from the mission bugs. I knew when I bought it that there were a lot of bugs, but i thouht performance was optimised for multi core/high end gpus and perform well on said hardware. I know at the moment my SLi is not working properly, so card is really a gtx275. I will loan my mates GTX285 and 4890 to test see which works best and i think the 4890 will beat out my gtx295

Helmut_AUT
Jun 10 2009, 13:57
Frag, what fillrate and settings are you using?

It's a bit shocking that your system suffers frame drop, since I wouldn't know what else short of a cray we could use instead.

householddog
Jun 10 2009, 14:01
I had a bit of a play around with this in the editor.

The method I used was to hide behind corner, then strafe into the open slightly. Keeping my orientation the same way.

What I found was interesting. Some buildings' walls do actually raise my fps higher by around 10-15 frames. Other ones do not. Particularly wooden buildings, I believe do not increase your fps when they block your sight. Concrete ones do not, as far as I can tell.

Some sort of penetration/los madness? Not sure yet. Just an early observation. You guys/gals, might want to try it, and see if you get the same results.

SANGEKi
Jun 10 2009, 14:04
I also have a Core i7 at 4.2 GHz with HT enabled.
I "only" have GTX280 at the moment and my FPS are OK...ish as long as I stay low with the resolution (not so easy on a 30" monitor) but there is only so much more hardware out there that you can put into your computer.

MadDogX
Jun 10 2009, 14:12
I also have a Core i7 at 4.2 GHz with HT enabled.
I "only" have GTX280 at the moment and my FPS are OK...ish as long as I stay low with the resolution (not so easy on a 30" monitor) but there is only so much more hardware out there that you can put into your computer.

Can you post a screenshot of your gfx settings screen, including the advanced options?

SANGEKi
Jun 10 2009, 14:23
Can you post a screenshot of your gfx settings screen, including the advanced options?

Not really. ;)

I don't have any set settings right now and I don't really play the game at the moment.

As I said the game runs OK as long as I don't exactly run it on 2560x1600.

On everything maxed out, at 1680x1050, fillrate at 100% and visibility at about 4000 I get between 60 and 25 or so on average.


I'm not asking for support, the game runs how it's supposed to on my system.
I'm just not satisfied with the way it actually is supposed to run.

FraG_AU
Jun 10 2009, 14:31
Frag, what fillrate and settings are you using?

It's a bit shocking that your system suffers frame drop, since I wouldn't know what else short of a cray we could use instead.

1920x1200
Fill rate 100% (set manually in .cfg)
Settings

Viewdistance = 3.5k
Textures - Very High
Text memory - Very High
AA - High

Terrain/Object/Shadow - Normal

PP - LOW

Now I have played with all settings one by one and FRAPs, doing a little benchmark by running around a set course (not 100% accurate but it gives you and idea)

I run once to load the textures into memory, then record it.

Basically Textures drop my AVG by 1 going from Low to Very High
texture memory, Like wise Anistroptic filtering does not affect my performance at all.

Draw distance is negligable performance diff say going from 2500-4000 may lose 2 fps..

Like I said I am having difficulty in getting SLi going, I am just about to try after cleaning out drivers (I tried 4 drivers to see if any diff).. Going back to 186.08 now.

EDIT:
WOW FINALLY: Got SLi working!! Things I tried before but worked after using driver cleaner and re-installing drivers.. or could be new profile I made using nhancer?

Anyway what i did is clean drivers, install 186.08
I run game with -winxp -cpucount=8

Nhancer profile is copied from Arma 1, but I enabled multi core optimisation and of all things I used AFR-4 (Quad sli) * I have previously tried evry single setting in nhancer and didn't work *

Anyway that fixes one problem, no doubt nvidias next driver set should encompass a native profile for this game that works properly. I know I have been trying for days to get SLi going and when i almost gave up it seems to have kicked in.. I will do more testing and see what was the cause, as I know a lot of others were having SLi woe's, some managed to fix via "crysis.exe" trick, some used -winxp etc..

Helmut_AUT
Jun 10 2009, 14:37
Yep, that's the magical question: Why does changing detail settings have basically zero influence on frames at high resolution.

What I do notice is that people with this kind of problems generally run more than 1280x1024, which leads me to believe it is somewhat shading related. Pixelshading should be the one demand that really scales with resolution, no?

DMarkwick
Jun 10 2009, 14:49
I will check that, but as far as I know that house has no "see trough" windows.

It might not matter that there is not a window, the issue might be that the possibility of the wall having a window/transparent texture exists (even if it does not actually exist) and so the geometry behind the wall is at least calculated, if not rendered.

As another test, you might try manually placing 4 buildings all around your position in the editor, with no gap between them. Then do a slow 360 and noting the FPS at each point. My feeling is that stuff that gradually leaves your FOV, or that goes behind you, is culled as irrelevant to transparency concerns.

Helmut_AUT
Jun 10 2009, 14:53
Okay I get what you are saying - but then that's still something unnecessary, isn't it?

Just because you could theoretically look trough a hypothetical window in the house doesn't mean they can't cull if there isn't a window.

It goes a bit with above tests - maybe material is not only used for penetration but also for culling, so wood - often seen on fences and other "see-trough stuff" might have different culling than concrete.

DMarkwick
Jun 10 2009, 15:02
Okay I get what you are saying - but then that's still something unnecessary, isn't it?

Just because you could theoretically look trough a hypothetical window in the house doesn't mean they can't cull if there isn't a window.

Well, possibly, my interest in game engines is strictly amateur, but we all know that ArmA/ArmA2's engine is necessarily different from other games in that it needs to be open and all structures have the possibility of being destroyed. So there is no possibility of optimisation techniques like BSP trees etc, because there is no permanent geometry apart from the terrain.


It goes a bit with above tests - maybe material is not only used for penetration but also for culling, so wood - often seen on fences and other "see-trough stuff" might have different culling than concrete.

You might be right about that, but I think it's more likely to be related to view geometry. Perhaps both are used.

Meek
Jun 10 2009, 15:32
Is the concept really that hard to grasp? If you are inside a town or village, you are looking towards walls ALL of the time. Not towards ONE specific wall, but you are basically encircled by walls, and if the engine renders stuff behind those walls it's absolutely pointless for gameplay, bad for performance.

What you said was completely correct, but you are forgetting an important factor.

The game needs to determine if you are able to see the object behind that building or not.

In most FPSes (Half-Life 2 for example) what parts of the map the player can/can't see is determined when the map is being compiled, this works well in such games, where the game is mostly inside buildings and confines areas.

ArmA2 would not be able to use the pre-compiled check of what the player can/can't see because buildings are destructible. This means that a more computationally expensive method of determining hidden objects would be used, and that it must be done at runtime, and for a much larger area of the map. A hidden object check in ArmA2 would be substantially more computationally expensive than regular FPSes.

Let's take a look at some examples.

Flying an aircraft
Parachuting
Standing on the top of the hill
Standing in the middle of a field
Standing in a forest
Standing on top of a tall building

Under most circumstances you will be able to see nearly everything, running a hidden object check would most likely result in something we already know, nearly everything is visible. Congrats, you just wasted processing power. Frames were potentially dropped :butbut:.

Let's say you are inside a structure or inside a city, this is the only time when a hidden surface removal would be profitable, framerate improves significantly :yay:. But at the cost of frames being dropped in all other situations.

ArmA2 is not the only game that doesn't do hidden surface removal checks, it's quite common in games that are sandboxy.

Do not misinterpret me, I think there is lots of room for optimisation, but this isn't one of them.

Helmut_AUT
Jun 10 2009, 15:58
Valid point, good argument. The irony is of course that those few places where a visibility check might actually help are those were a lot of detail is visible and slows down GFX considerable.

And I'd still love to find out what the deal is when looking at the ground. I think these are separate things we're looking at here - one is the lack of culling/frame rate improvement when facing a wall, the other is that there seems to be a constant rendering overhead even if there is REALLY nothing in your view except a ground texture.

Oh, found something else: http://forums.bistudio.com/showthread.php?p=1305947#post1305947

The color grading in some missions is purely done by shader, they can also add film grain. While it looks cool I wonder if that doesn't confirm my assumption that a lot of the bottlenecks we are seeing at high res are actually shaders. I know for example in SH4, enabled post processing costs 20% frame rate. Here this almost seems like they have different layers of post processing stacked onto each other, which would explain why even monster cards struggle with high resolutions.

DMarkwick
Jun 10 2009, 16:19
And I'd still love to find out what the deal is when looking at the ground. I think these are separate things we're looking at here - one is the lack of culling/frame rate improvement when facing a wall, the other is that there seems to be a constant rendering overhead even if there is REALLY nothing in your view except a ground texture.

I think, if we take the previous explanations as valid, then it's possibly as simple as culling taking place on a purely horizontal directional basis. That is, the same culling is done on your orientation whether or not you're looking up or down. A simple cull of all objects behind your left & right bearings.


Oh, found something else: http://forums.bistudio.com/showthread.php?p=1305947#post1305947

The color grading in some missions is purely done by shader, they can also add film grain. While it looks cool I wonder if that doesn't confirm my assumption that a lot of the bottlenecks we are seeing at high res are actually shaders. I know for example in SH4, enabled post processing costs 20% frame rate. Here this almost seems like they have different layers of post processing stacked onto each other, which would explain why even monster cards struggle with high resolutions.

I think you're right that a lot of FPS is gobbled up by fancy shaders. I'd like the opportunity to lose as many as I want for SP play certainly.

ECH
Jun 10 2009, 17:18
Thats exactly what they are trying to point out, massive problem with the graphics engine. This clearly displays that people are NOT getting the performance they should with the same amount of detail.

---------- Post added at 12:20 AM ---------- Previous post was at 12:15 AM ----------

This is called overdraw right? So this would mean that the graphics engine isn't properly communicating with the graphics cards. Therefor the graphics cards processing depth that you cant see. Which ultimately means that once again, BIS has not optimized correctly for the graphics cards.
So is this a problem when using ATI? Nvidia? or both?

SANGEKi
Jun 10 2009, 17:31
So is this a problem when using ATI or Nvidia video cards?

It's a "problem" with the engine itself.

ECH
Jun 10 2009, 17:33
... My system is

i7 @<hidden> 4.2Ghz
6Gb RAM 1600
GTX295 OC'ed
...I will loan my mates GTX285 and 4890 to test see which works best and i think the 4890 will beat out my gtx295

Once you do this could you create a new thread discussing the results? I would look forward to reading what you observed, thanks!

POTS
Jun 10 2009, 19:49
What you said was completely correct, but you are forgetting an important factor.

The game needs to determine if you are able to see the object behind that building or not.

In most FPSes (Half-Life 2 for example) what parts of the map the player can/can't see is determined when the map is being compiled, this works well in such games, where the game is mostly inside buildings and confines areas.

ArmA2 would not be able to use the pre-compiled check of what the player can/can't see because buildings are destructible. This means that a more computationally expensive method of determining hidden objects would be used, and that it must be done at runtime, and for a much larger area of the map. A hidden object check in ArmA2 would be substantially more computationally expensive than regular FPSes.

Let's take a look at some examples.

Flying an aircraft
Parachuting
Standing on the top of the hill
Standing in the middle of a field
Standing in a forest
Standing on top of a tall building

Under most circumstances you will be able to see nearly everything, running a hidden object check would most likely result in something we already know, nearly everything is visible. Congrats, you just wasted processing power. Frames were potentially dropped :butbut:.

Let's say you are inside a structure or inside a city, this is the only time when a hidden surface removal would be profitable, framerate improves significantly :yay:. But at the cost of frames being dropped in all other situations.

ArmA2 is not the only game that doesn't do hidden surface removal checks, it's quite common in games that are sandboxy.

Do not misinterpret me, I think there is lots of room for optimisation, but this isn't one of them.

Ah, what you say does make sense, but only if its equaly computationaly expensive to shut it down as it is to start it up. So I still dont think it would be a bad thing. But you still talk like a CPU is a weak part of your computer and it is not. A small counting control algorithm wouldn't be that hard to shutdown in the internal threads.

EDIT: Could you tell me what kind of other games do this?

rowdied
Jun 10 2009, 20:37
1920x1200
Fill rate 100% (set manually in .cfg)
Settings

Viewdistance = 3.5k
Textures - Very High
Text memory - Very High
AA - High

Terrain/Object/Shadow - Normal

PP - LOW

Now I have played with all settings one by one and FRAPs, doing a little benchmark by running around a set course (not 100% accurate but it gives you and idea)

I run once to load the textures into memory, then record it.

Basically Textures drop my AVG by 1 going from Low to Very High
texture memory, Like wise Anistroptic filtering does not affect my performance at all.

Draw distance is negligable performance diff say going from 2500-4000 may lose 2 fps..

Like I said I am having difficulty in getting SLi going, I am just about to try after cleaning out drivers (I tried 4 drivers to see if any diff).. Going back to 186.08 now.

EDIT:
WOW FINALLY: Got SLi working!! Things I tried before but worked after using driver cleaner and re-installing drivers.. or could be new profile I made using nhancer?

Anyway what i did is clean drivers, install 186.08
I run game with -winxp -cpucount=8

Nhancer profile is copied from Arma 1, but I enabled multi core optimisation and of all things I used AFR-4 (Quad sli) * I have previously tried evry single setting in nhancer and didn't work *

Anyway that fixes one problem, no doubt nvidias next driver set should encompass a native profile for this game that works properly. I know I have been trying for days to get SLi going and when i almost gave up it seems to have kicked in.. I will do more testing and see what was the cause, as I know a lot of others were having SLi woe's, some managed to fix via "crysis.exe" trick, some used -winxp etc..

I'm glad to hear because I was running the dgame with your exact settings and was getting the same results with my Q9550 @<hidden> 3.4 and a gtx 260.
How is the 295 working now and what are your fps?

FraG_AU
Jun 11 2009, 04:11
I'm glad to hear because I was running the dgame with your exact settings and was getting the same results with my Q9550 @<hidden> 3.4 and a gtx 260.
How is the 295 working now and what are your fps?

Funny thing is that it has not changed much in the "cities' Still 30-35avg. Maybe why I didn't pick it up earlier.

In the wilderness its 40-60fps with avg of 48.

Before I was getting 29fps no matter what I did, whether I had shadows full or not etc..

I still think SLi is not being fully utilised but, new drivers bring new hope ;) The load balancing graph shows 65-70% Sli efficiency which is not the best!

Fresh![NUTZ]
Jun 11 2009, 06:27
Fascinating thread gentlemen...since the engine is new, we can only hope it will be optimized over time with the observations you bring to the table. Perhaps there are unforeseen engine characteristics causing these FPS differences. I have a good feeling things are going to be ironed out, as they always have been in previous engines.

In the meantime, I'm still having a hoot in multiplayer. I have my settings on 'very low' until I upgrade my video card, the engine seems fine and it's still beautiful!

Balgorg
Jun 11 2009, 06:54
The Arma 2 engine is just an updated version of the Arma 1 engine, itself updated from OFP. So thats the problem. Yes this game, and all the games in the linup are great modern warfare simulations, but how many times can you 'update' and engine?

So i recon the problem comes from the fact that BI need to develop a new engine from scratch. Imagine if the Quake engine from ID was endlessly recycled. ID realised that rather than updating an engine its better to make a new one. That way the engine can be styled from the ground up to produce the effects you need, and during development any major bottlenecks can be ironed out.

With Arma 2 they have been adding greater detail, more effects, and more complex AI, to an ageing engine. Sure the code has had a major over hall, but underneath its an old codger.

Razorman
Jun 11 2009, 07:38
;1306614']Fascinating thread gentlemen...since the engine is new, we can only hope it will be optimized over time with the observations you bring to the table. Perhaps there are unforeseen engine characteristics causing these FPS differences. I have a good feeling things are going to be ironed out, as they always have been in previous engines.

In the meantime, I'm still having a hoot in multiplayer. I have my settings on 'very low' until I upgrade my video card, the engine seems fine and it's still beautiful!

Sorry to burst you bubble but this is NOT a new engine, it's a very old engine that's been constantly updated, this is ARMA 1.5 final, not ARMA 2.

Updated too much imho, it can't cope with whats being asked of it performance wise.

householddog
Jun 11 2009, 07:51
I tried out the same experiment in COD4. It doesn't seem to give any frame rate increase when stepping out from a wall.

Its possible it could be due to the insane frame rates I am getting (250fps) I am not really sure.

I played around with zbuffer settings using atitray, it really didn't seem to make much difference.

---------- Post added at 07:51 AM ---------- Previous post was at 07:48 AM ----------


Sorry to burst you bubble but this is NOT a new engine, it's a very old engine that's been constantly updated, this is ARMA 1.5 final, not ARMA 2.

Updated too much imho, it can't cope with whats being asked of it performance wise.

Dunno if its really updated either. You can pump huge renders, polys etc even into very old 3d engines.
You could even try replicating this Arma on the old DoomI 2D engine. It just a matter of getting very inefficient result. IE, what we are seeing now. ;)

Shadowclaw
Jun 11 2009, 09:35
Okay, this gets to the point where I really have to believe the engine has code problems or design problems. I can't explain it any other way, and I would really appreciate if we can hear from the devs here.

Using a GF9600GT, everthing to low except textures (normal) and shadows (normal), VD 1200, Fillrate 100% at 1920x1200.

Now, the test:

On the small island in Utres, walk to the first wooden house in Strelka, the first on the right as you come up from the beach.

Drop your gun.

Walk up to the house facing NW and place yourself directly in front of a stretch of wooden wall with NO windows or anything in it. With your nose touching the house, so the house blocks everthing else, straight on.

Gives me 24 FPS.

Now, I move to the opposite side of the house, walk up to a bare stretch of wood wall, and do the same.

34 FPS.

That's a 40% frame difference. Looking at the SAME texture from the SAME distance with nothing else on the screen.

I really can only explain this by assuming that they are not properly culling background objects as they get blocked by other things. Because when you are looking SE at the house, behind it is mostly open ocean. When you are staring NW "trough the house" you are looking at the destroyed church.

I have no way to take apart the engine and know what BIS has done here, but I do know that 40% framerate difference looking at the same texture should not happen. Can someone throw this on the bugtracker please?

I suppose the diffrence is really what the engine tries to do in the background. If it would just count this 1 texture it would give you insane fps but when you would turn around to look somewhere else your fsp would drop below ground zero because they haven't been "pre-calculated" what would make for a horrid game experience. At some point the diffrence in fps is logical.

I sure think you could optimize everything to a far better result than it is now.

Helmut_AUT
Jun 11 2009, 13:35
Okay, I now believe the poster who said A2 is totally CPU-bound.

With new 185 drivers, some detail changes and Keygets no-blur mod, I was able to raise my avg. in my "Strelak" benchmark to 29 from 22. Even if I apply the color correction function that tints everthing brownish.

But when I play "Trial by Fire" SP mission, with only a handfull of units - my framerate tanks down to 22.

This is the same village, same graphic settings, same color correction applied - it must be CPU-reasons why I'm seeing such decrease.

The graphics engine still is slow - still only gives me 18 fps sometimes in forrests or worse. I still believe it needs optimizing. But that doesn't matter when even the smaller SP missions already bottleneck me on a 5000+ AMD (which is better than recommended specs).

Von_Paulus
Jun 11 2009, 14:43
But that doesn't matter when even the smaller SP missions already bottleneck me on a 5000+ AMD (which is better than recommended specs).


Remember that your CPU has only 512Kbx2 in L2 cache. That's a bottleneck for sure.

FraG_AU
Jun 11 2009, 15:49
Funny thing is that it has not changed much in the "cities' Still 30-35avg. Maybe why I didn't pick it up earlier.

In the wilderness its 40-60fps with avg of 48.

Before I was getting 29fps no matter what I did, whether I had shadows full or not etc..

I still think SLi is not being fully utilised but, new drivers bring new hope ;) The load balancing graph shows 65-70% Sli efficiency which is not the best!

OK, did more tests my SLi is not working, back to square 1. What happened is my game crashed during some driver testing and reverted back to higher details, my fps boost simply came from lowering shadow detail/object detail to normal..

(PS> My avdanced settings tab was not coming up, I may have write protected the .cfg file when I was trying something)..

So yeah no SLi still.

Cionara
Jun 11 2009, 16:34
I haven't read the whole thread but what you describe in the first post is the same like when you're standing near a tree. It only happens on the shadow side. Like with the house, looking into the direction of the sun.
It's the HDR that does this framedrop. With a setting in the menu to disable HDR I think it would be a lot better. But they have to patch such a setting into the game.

There's Kegetys mod but it doesn't disable it, it just lays a new mask on the screen and Arma2 calculates the HDR although.

POTS
Jun 11 2009, 19:37
The Arma 2 engine is just an updated version of the Arma 1 engine, itself updated from OFP. So thats the problem. Yes this game, and all the games in the linup are great modern warfare simulations, but how many times can you 'update' and engine?

So i recon the problem comes from the fact that BI need to develop a new engine from scratch. Imagine if the Quake engine from ID was endlessly recycled. ID realised that rather than updating an engine its better to make a new one. That way the engine can be styled from the ground up to produce the effects you need, and during development any major bottlenecks can be ironed out.

With Arma 2 they have been adding greater detail, more effects, and more complex AI, to an ageing engine. Sure the code has had a major over hall, but underneath its an old codger.

I dont know how a completely new engine will help arma2. So I guess you want MORE bugs to fix? Besides, if BIS were to attempt to create a new engine, it would look very much like their current one, just with more bugs.

Balgorg
Jun 11 2009, 21:41
I dont know how a completely new engine will help arma2. So I guess you want MORE bugs to fix? Besides, if BIS were to attempt to create a new engine, it would look very much like their current one, just with more bugs.


I dont agree, many other developers have had success through the abandonment of their earlier engine.

Certainly tinkering with an existing engine can have decent results, examples of this are how the Quake engine was morphed into the Quake 2 engine. ID then abandon's the old build and came up with the Quake 3 engine. Other developers took the Quake 2 engine and modified it with great results, Halflife 1 is an example, also Daikatana (naff game, but great use of the older engine).

ID took the Quake 3 engine and developed it until they realised a new approach was needed, hence the Doom 3 engine. At the moment Carmac is working on a new engine.

Thing is, have you ever heard of major problems with these game engines? Over the years I have never had a single problem with any of ID's engines. Its different with COD 4's build of the Doom 3 engine, they have modified the existing build and this has led to incompatability and instabilty for many people.

I think that BI need to start again, and make Arma 3 all new. Sure it might be very much like the old engine, but it would be designed with modern hardware in mind. Fully use DX10, Quad cores and SLI with no problems. All the 3 latter are currently an issue with this arma 2 engine.

POTS
Jun 11 2009, 21:48
I dont agree, many other developers have had success through the abandonment of their earlier engine.

Certainly tinkering with an existing engine can have decent results, examples of this are how the Quake engine was morphed into the Quake 2 engine. ID then abandon's the old build and came up with the Quake 3 engine. Other developers took the Quake 2 engine and modified it with great results, Halflife 1 is an example, also Daikatana (naff game, but great use of the older engine).

ID took the Quake 3 engine and developed it until they realised a new approach was needed, hence the Doom 3 engine. At the moment Carmac is working on a new engine.

Thing is, have you ever heard of major problems with these game engines? Over the years I have never had a single problem with any of ID's engines. Its different with COD 4's build of the Doom 3 engine, they have modified the existing build and this has led to incompatability and instabilty for many people.

I think that BI need to start again, and make Arma 3 all new. Sure it might be very much like the old engine, but it would be designed with modern hardware in mind. Fully use DX10, Quad cores and SLI with no problems. All the 3 latter are currently an issue with this arma 2 engine.

You know how old the source engine is? DX10 is not that good, dont buy into that please. And the engine is called real virtuality 3 btw. ArmA used real virtuality 2.

DaveG
Jun 11 2009, 23:40
I doubt it's the hdr causing the slowdown since it's working all the time. It's most likely to do with the z buffer which all games use to make sure stuff that's behind other stuff doesn't get drawn in front of it. If there was no z buffer the objects would need to be sorted front to back, by distance from the camera each frame. this will be very slow! using a z buffer is much quicker but from different view points there will be different amounts of pixels that are overdrawn (rendered more than once) and thus you can have different frame rates looking at the same textured polygon depending on what stuffs behind it and what order the data is presented in.

POTS
Jun 12 2009, 03:20
I doubt it's the hdr causing the slowdown since it's working all the time. It's most likely to do with the z buffer which all games use to make sure stuff that's behind other stuff doesn't get drawn in front of it. If there was no z buffer the objects would need to be sorted front to back, by distance from the camera each frame. this will be very slow! using a z buffer is much quicker but from different view points there will be different amounts of pixels that are overdrawn (rendered more than once) and thus you can have different frame rates looking at the same textured polygon depending on what stuffs behind it and what order the data is presented in.

But is losing 15 fps normal? Like I said, 1-5 fps I wouldn't care to much, but 15?

Törni
Jun 12 2009, 03:57
Changing my graphics card from 9600gt to 260gtx did wonders for me. With the older card the game was suffering from slow downs. With the new card I get 100+ frames by looking into sky. You can just forget about running the game in high resolutions with mid range cards.

soldier9945
Jun 12 2009, 05:41
Changing my graphics card from 9600gt to 260gtx did wonders for me. With the older card the game was suffering from slow downs. With the new card I get 100+ frames by looking into sky. You can just forget about running the game in high resolutions with mid range cards.

What do you get in the third SP mission "Gegenangriff" when you are in the hallway in town where the first savegame occurs? (in FPS).
With these ingame settings:
Every option on "Very High", View Distance: 3600, Fillrate 100% @<hidden> 1680x1050, Veteran mode (for AI settings maxed out).


Would interest me, as a friend will buy this card soon :o Thanks!

DaveG
Jun 12 2009, 07:41
But is losing 15 fps normal? Like I said, 1-5 fps I wouldn't care to much, but 15?

It could well be. There probably be a lot of overdraw anyway due to all the foliage. And you were near the coast when doing the test so one direction may have had not a lot but sea behind it.

POTS
Jun 12 2009, 08:31
This is a two dimensional representation of how things should be blocked out. The black area represents objects located on the visualy blocked grid.

Here is how a single wall would block out objects located on the visualy blocked grid.

http://img38.imageshack.us/img38/3103/occlusione.png

Here is how multiple walls block out objects on the visualy blocked grid. Notice how the black areas add up and sometimes create one black area.

http://img193.imageshack.us/img193/8658/blockedview.png

Using a 3d grid could give objects an assigned location in 3d space. And having an algorithm that assigns objects to be blocked because of their location within the blocked area should not be too CPU demanding like some say. Its fairly simple for the CPU to handle.

Now, arma2 already has a 3d grid that handles object location, so there should be no real excuse to not have something like this fully functioning.

DaveG
Jun 12 2009, 10:25
Seriously this is what the z-buffer is for! It's pretty much the most efficient way of dong this and is handled in hardware with little input from the programmer.

Doing it the way you suggested would involve computing the distance from the camera to each and every polygon in the scene which needs at least one square root (=very slow) per polygon. Then of course all the polygons (probably 10's of thousands) to be sorted according to this depth and rendered accordingly.

Trust me, BI know what they're doing!

moosenoodles
Jun 12 2009, 11:48
Anyone tried forcing the z buffer to 16 or 24 bit? Can do that with certain tools for your card.

Alex72
Jun 12 2009, 11:55
It will take objects behind the house in consideration as well. If there is a forest behind the wall looking one way and the sea looking the other way there will be FPS difference.

If thats a coding error i dont know. Dont think so though.

Alex

DaveG
Jun 12 2009, 12:34
Anyone tried forcing the z buffer to 16 or 24 bit? Can do that with certain tools for your card.

The might help if there are any z-fighting issues (flickering decals and textures) but it won't help with overdraw.

Yoma
Jun 12 2009, 12:39
This is a two dimensional representation of how things should be blocked out. The black area represents objects located on the visualy blocked grid.

Here is how a single wall would block out objects located on the visualy blocked grid.

http://img38.imageshack.us/img38/3103/occlusione.png

Here is how multiple walls block out objects on the visualy blocked grid. Notice how the black areas add up and sometimes create one black area.

http://img193.imageshack.us/img193/8658/blockedview.png

Using a 3d grid could give objects an assigned location in 3d space. And having an algorithm that assigns objects to be blocked because of their location within the blocked area should not be too CPU demanding like some say. Its fairly simple for the CPU to handle.

Now, arma2 already has a 3d grid that handles object location, so there should be no real excuse to not have something like this fully functioning.

I honestly know nothing about 3d engines, but maybe the engine need to precache some stuf so things can get drawn quicker if you shift position/turn around etc. It's not only about actual rendering, it's allso trying to make sure textures are in cache.
It might be a bug though, also i cannot reproduce this behaviour on my system. (q9650+285GTX)

DaveG
Jun 12 2009, 12:44
The game most definitely already does this. OFP did it, Arma did it, I'm sure this game does it too.

householddog
Jun 12 2009, 13:23
Anyone tried forcing the z buffer to 16 or 24 bit? Can do that with certain tools for your card.
Yeah, as I said before, I tried it. No noticeable difference.

ATI Tray tools does it for ATI cards.

moosenoodles
Jun 12 2009, 15:18
Yeah, as I said before, I tried it. No noticeable difference.

ATI Tray tools does it for ATI cards.


Yeah shouldnt I think do much as its an opengl adjustment, but im sure ive read before that you can use it otherwise. Thing is i forced it to 24 earlier and flew around the map in heli's nice and 50>100 fps :D and did not see one shimmering dual loading texture plain on the windows of doors etc etc..

Could be just random luck though, this engine has me in fits at times with its irregularities :D

householddog
Jun 12 2009, 16:09
Could be just random luck though, this engine has me in fits at times with its irregularities :D
Its bizarre. I am having an argument in another thread with somebody who thinks Arma2 scales well to hardware.

I really don't see it myself.

anfiach
Jun 12 2009, 16:41
The simple answer could be poly count and the construction of the building. It looks the same but internally it may not be.

householddog
Jun 12 2009, 17:01
Yes but then you would expect the fps to change if it were the polys. It pretty well stays exactly the same, when you look at it.

At the very least there should be sweet FA rendering going on.

Obviously the game is culling renders out of your field of view. You need only look up at the sky to see that.

Its simply not using occlusion culling, in a lot of places.

I wonder if it still renders everything on the other side of a hill too?

anfiach
Jun 12 2009, 23:11
Yes but then you would expect the fps to change if it were the polys. It pretty well stays exactly the same, when you look at it.


Why would it change while you are staring at it?

householddog
Jun 13 2009, 15:14
Why would it change while you are staring at it?

I mean it should change, either for the better or worse, when you look at it. As opposed to strafing it out of view. If there were more polys, there should be less fps, if there are less poly then more fps. As it is, there is no difference whatsoever, with a lot of buildings/objects.

If its rendering things behind the object that would explain why the FPS would not change.

Its not an entirely conclusive test, I agree, but interesting, non the less.

anfiach
Jun 13 2009, 17:08
I mean it should change, either for the better or worse, when you look at it. As opposed to strafing it out of view. If there were more polys, there should be less fps, if there are less poly then more fps. As it is, there is no difference whatsoever, with a lot of buildings/objects.

If its rendering things behind the object that would explain why the FPS would not change.

Its not an entirely conclusive test, I agree, but interesting, non the less.The OP was about one wall showing lower FPS than another, this is why I am confused by your statement.

Dwarden
Jun 13 2009, 21:44
erm most modern drivers support 32bit Z-buffer (or 24+8) ... what was the point lower to 16,24 ?

householddog
Jun 14 2009, 13:29
erm most modern drivers support 32bit Z-buffer (or 24+8) ... what was the point lower to 16,24 ?
To test if it would lower my frame rate.

I didn't know it was opengl though. My mistake.

---------- Post added at 01:29 PM ---------- Previous post was at 12:41 PM ----------

Maybe its got something to do with the destructible landscape.

Warmbrak
Jun 14 2009, 16:23
Well, not entirely what has been experienced here, but to the same effect. I played the OFP missions ported for ARMA 2, and during the Cleansweep I missions I saw this anomaly for the first time. My two teammates died quickly in the mission, and I sneaked around to get to them to loot them for ammo. The framrates were quite good troughout. I then reached the body of a dead teammate and dragged it out of the road to behind a fence. It is here that my problems started. I did not matter at which point I was in the village after that or how many buildings were between me and his body, once I moved my view so that he is within the limits of my screen (although he is not visible), my framerates would drop to a slideshow.

I tested it extensively and could identify it as the culprit. So after the "drag" command was executed on the body, things went downhill. I tried it deliberately with the second teammate as well, and the same effect. I experienced the same kind of slowdown during the second stock ARMA 2 SP mission (can't remember the name), but the squad of rebels that attacked the town. We killed the BMP (or whatever it was), and for the remainder of the mission, something in that area killed the framerates when my screen was oriented in that direction.

I am only guessing that there might be some effects/scripts that are acting up when you view in the direction of the object that is executing that command - whether they are in plain line of sight or behind a building(s).

Scruffy
Jun 14 2009, 16:58
...

The problem here is the blood. If the first aid systems are used and a unit linked with them dies they bleed out and leave a growing pool of blood. When you pull them around you make things even worse as you now leave a trail of blood.

http://www.abload.de/thumb/arma22009-06-1412-56-4l02w.jpg (http://www.abload.de/image.php?img=arma22009-06-1412-56-4l02w.jpg) http://www.abload.de/thumb/arma22009-06-1412-58-4z637.jpg (http://www.abload.de/image.php?img=arma22009-06-1412-58-4z637.jpg)
http://www.abload.de/thumb/arma22009-06-1413-00-0k2ma.jpg (http://www.abload.de/image.php?img=arma22009-06-1413-00-0k2ma.jpg) http://www.abload.de/thumb/arma22009-06-1413-00-130ee.jpg (http://www.abload.de/image.php?img=arma22009-06-1413-00-130ee.jpg) http://www.abload.de/thumb/arma22009-06-1413-00-1j6r1.jpg (http://www.abload.de/image.php?img=arma22009-06-1413-00-1j6r1.jpg)

Helmut_AUT
Jun 15 2009, 10:50
The OP was about one wall showing lower FPS than another, this is why I am confused by your statement.

Not quite correct - my OP was about the difference it makes in FPS what lies behind a wall, when in fact everthing behind it could be culled from rendering - or maybe not, as some people here explained for other reasons.

But my test was not to show that two walls have different FPS - rather to show the engine is rendering stuff you can't see.

Razorman
Jun 15 2009, 12:47
The problem here is the blood. If the first aid systems are used and a unit linked with them dies they bleed out and leave a growing pool of blood. When you pull them around you make things even worse as you now leave a trail of blood.

http://www.abload.de/thumb/arma22009-06-1412-56-4l02w.jpg (http://www.abload.de/image.php?img=arma22009-06-1412-56-4l02w.jpg) http://www.abload.de/thumb/arma22009-06-1412-58-4z637.jpg (http://www.abload.de/image.php?img=arma22009-06-1412-58-4z637.jpg)
http://www.abload.de/thumb/arma22009-06-1413-00-0k2ma.jpg (http://www.abload.de/image.php?img=arma22009-06-1413-00-0k2ma.jpg) http://www.abload.de/thumb/arma22009-06-1413-00-130ee.jpg (http://www.abload.de/image.php?img=arma22009-06-1413-00-130ee.jpg) http://www.abload.de/thumb/arma22009-06-1413-00-1j6r1.jpg (http://www.abload.de/image.php?img=arma22009-06-1413-00-1j6r1.jpg)

Nice find! Let's hope the devs see this & implement a fix?

anfiach
Jun 15 2009, 16:07
Not quite correct - my OP was about the difference it makes in FPS what lies behind a wall, when in fact everthing behind it could be culled from rendering - or maybe not, as some people here explained for other reasons.

But my test was not to show that two walls have different FPS - rather to show the engine is rendering stuff you can't see.
You are assuming it is what is behind the wall that is causing the difference given your orientation but if this is the case it will not just be that one specific wall where you will see the differences.

EDIT: I am not saying that you are incorrect, just that given the information you stated, a definitive conclusion cannot be drawn.

ECH
Jun 16 2009, 20:23
Are we there yet?

Can we get reduced background culling when we objects block our view based on field of draw rendering (or whatever they call it)?

Helmut_AUT
Jun 17 2009, 08:58
You are assuming it is what is behind the wall that is causing the difference given your orientation but if this is the case it will not just be that one specific wall where you will see the differences.

EDIT: I am not saying that you are incorrect, just that given the information you stated, a definitive conclusion cannot be drawn.

I tested it with more than just one wall... yes, the conclusion can be made that culling doesn't happen as much as it could.

neptar
Jun 19 2009, 15:28
The engine is just terrible. I know the terrain is huge and that is a lot to take in. But the engine is just really poor. It's like this game is a student project.

I really hope they do something about these problems. The game isn't playable at 50-60 fps for me. I get severe mouse lag unless i have like over 120 fps. Which means playing with everything real low, or looking at the sky all the time..... I just wish I could play the game properly.

Razorman
Jun 19 2009, 15:32
The engine is just terrible. I know the terrain is huge and that is a lot to take in. But the engine is just really poor. It's like this game is a student project.

I really hope they do something about these problems. The game isn't playable at 50-60 fps for me. I get severe mouse lag unless i have like over 120 fps. Which means playing with everything real low, or looking at the sky all the time..... I just wish I could play the game properly.


That's a sweeping statement to make, game looks & plays superbly here on the rig below, what are your pc specs?

FraG_AU
Jun 20 2009, 06:44
Ok, was just going through my fraps images and I came accross this, which I know we have all seen.

http://www.overclockers.com.au/pix/image.php?id=0wnqn&f=1'
Click to view full size! ('http://www.overclockers.com.au/pix/index.php?page=image&id=0wnqn')

Why should I be able to see the cow in this picture. It sort of backs up that culling isn't being done properly ?

As soon as my "LOS" hits the hill it should abort the calculation and I should not know there is a cow on the otherside.

EDIT: Or is this actually adding complexity to the calculation

Espectro
Jun 20 2009, 08:04
This reminds me of the old bug in OFP - where you couldn't see objects when looking through the windshield of vehicles. A bug also present in some vehicles in ArmA. If I remember correctly, you could see houses, though... Right?

ECH
Jun 26 2009, 19:28
I wish this culling problem is fixed in a patch. So far I haven't seen it fixed yet!

Balgorg
Jun 26 2009, 20:20
Omg god, its all gone white and fuzzy !!!!!!!!

http://www.youtube.com/watch?v=jmKqecncMEo

Taciturnus
Jun 26 2009, 21:07
For a small team like BIS, Arma 2 is quite good. However, with the types of rigs people are running and the amount of performance they are getting leads me to believe that the engine is just old and kludgy and may have some deep and dirty design issues. Over the years features have been tacked on and made to work. I mean, we still have OFP era physics. Sure, you could write a engine from scratch with a good design but that's much easier sad then done.

A modern rewrite for Real Virtuality 4 engine would be awesome, but I guess you work with what ya' got.

Alex72
Jun 26 2009, 21:15
Got lesser rig than complainers and it runs damn fine. Dont know how you treat your pc's nor do i know if you over do the settings in-game.

Game is superb with some things to fix. Calling this a "student project" is quite childish.

Cpt.Goose
Jun 26 2009, 21:43
SoI never played Arma 1 but defiantly getting this when it comes out on store shelves in Canada. I'm reading a ton of performance issues though, people with midstream rigs getting normal/high mix settings and playing fine and then enthusiast pc's running on high and complaining.

Obviously we can see that the engine is either outdated or improperly/unpolished code for the engine. Then we have to take into account the level of detail both content and graphic/texture wise. We can expect this to be somewhat of a resource hog like most large, pretty looking games (ex. Crysis launch, Flight Sim X, etc.)

Couple questions though, 1. I have a E8400 Dual Core @<hidden> 3.0ghz, 4gb 1066mhz DDR2, EVGA 8800GTS 512mb G92, and Resolution @<hidden> 1680x1050. Can I expect a smooth gaming experience at medium/high settings? (anyone out there with similar specs?)

2. From Arma 1 when if first came out to Arma 1 today, patched and polished what performance gain did we see after the bugs, glitches, and engine was tuned/patched? Can we expect to see a fair increase in FPS with future patches? or a mere 4-5fps gain.

Balgorg
Jun 26 2009, 22:07
The engine is just terrible. I know the terrain is huge and that is a lot to take in. But the engine is just really poor. It's like this game is a student project.

I really hope they do something about these problems. The game isn't playable at 50-60 fps for me. I get severe mouse lag unless i have like over 120 fps. Which means playing with everything real low, or looking at the sky all the time..... I just wish I could play the game properly.


You will get fanboys stomping about in their bedsits with this post.......

I have similar problems running the game in Chernarus, with stuttering and LOD pop up, looks rubbish to me, but I ported over Sahrani from Arma 1. Then I can run at full settings and 1000 on the view distance, and still get 30+ fps. I got a mid range system. So if sahrani runs like that, it cant be the engine can it? Its Chernarus.

Over the years lots of maps have been made for the original Arma, and some just run terribly. The reason? To much clutter. If you compare Cheranus to other island maps, its massively complex. Not in terrain like Sahrani, and not in the towns and villages. Its all the trees, thousands of the buggers. Put up the view distance even a tad too far and your in for trouble, unless you got a super powerful system.

Chernarus then is like a badly developed island addon, where the maker has let their imagination go wild, and has sacrificed performance for realistic looks. For me and my system, it means ugly as, and like trying to walk through sludge.

Wait for some new islands to be released, and you will be pleasantly suprised.