earl

Repositioned, but not shafted: https://forums.bisimulations.com/viewforum.php?f=18 "General Discussion: Open discussion area for serious gamers and content developers."

How can it fly if the propeller isn't spinning? I think it's photoshopped.

It seems all the cpu speed you can get is useful, more cores + overclocking seems to be very rewarding for Arma2 campaign (ai & script) performance. I haven't seen the benchmarking mission but i would think a some kind of camera script walkthrough ia high poly town would push graphics (gpu), then fast flyover across the island would show any paging slowdowns (hdd, also gpu) and finally an incrementally increasing AI numbers into a huge battle while the camera looks at sky/ground should be a good cpu proofing?

Is it possible to modify the poll to add another q? There may be other people like myself who got the game very recently, after patch 1.02 was released, so we would need a 'cannot comment' entry. Otherwise we can't see results if we don't vote. (I probably missed a 'skip vote' shortcut somewhere)

I was thinking to upgrade E6600 to Q6600 but the price isn't really favourable for such a relatively older CPU. I get similar 20-30 fps in the first third of the campaign. Much higher on an empty terrain via editor. I'm running 1920x1200, 100% fillrate, everything else on normal, post processing off, and view distance 1800-2200m. Nothing really seems to move the FPS at all, none of the graphical settings show much fps change. ASUS commando (P965) C2D E6600 2x1GB Corsair DDR2 800mhz GTX 260 core 216 Nothing is overclocked but I'm going to reconsider that plus get 2GB more ram, for the kinds of prices RAM goes for these days even if it doesn't help A2 so much it's about time. And I'm installing an SSD tonight, so that should do good things for paging.

I think its the best answer. 32768 vertices is a hard limit in ArmA -- as directx counts them. O2's points count is not quite the same thing depending on the number of sharp edges you have. I guess it applies to ArmA2 as well. I think its the max size of the vertex buffer. You'll know when you get there since buldozer fails to draw the model.

My suggestion is to start small, maybe there's even no judging at first, just have a subject, deadline, and a bit of fun. Get it started. After there's a few regulars start working out how the rest is going to work. Committees and overseers and delegates sounds a bit too ambitious right at the beginning. Open source submissions is a great idea.

Nice pics Monty, that last one is the al-Shaheed monument, or martyr's memorial (for iran-iraq war). http://en.wikipedia.org/wiki/Al-Shaheed_Monument

Just thought I would point out that you still need a "computer game" to see such an AAR. VBS2 can be used there too, and with good quality source data, the terrain can be recreated for a very useful 3D replay of a live training event.

I think Plaintiff explained it better than me :-) I'm pretty sure it's the vertex buffer limit per model. I can describe a cube with six quads (24 vertices), or with twelve triangles (36 vertices). Â A squarized P3D model is smaller filesize than the same model triangulated. Â That is all.

Model errors causing performance issues on a dedicated server that isn't rendering anything?

A squarized model will be a smaller P3D file than a triangulated one: Triangle 1 = Vert 1, 2, 3 Triangle 2 = Vert 2, 3, 4 Quad 1 = Vert 1, 2, 3 ,4 Probably only matters if you are storing a large collection of models and/or keeping version history. Â Doesn't matter once binarized. Â I hate looking at triangulated models, squarized is just easier on my eyes. There is no face count limit in ARMA, 10K triangles is just a sensible number. Â The limit is 32768 vertices as DirectX counts them. Â That's a bit tricky since what Oxygen considers a point != DirectX vertices, I don't know all the rules, but if buldozer fails to draw your model and you see a "Too many vertices" error msg, that is the reason. Â Often what we consider as a single mesh actually gets split up into different parts at runtime, which means more vertices than you saw reported as points in Oxygen. As an example, start O2 and Buldozer, create a sphere with the value 64 used in all 5 parameters. Â Copy it 4 times so you have 5 spheres in O2 and in Buldozer. Â 9930 points and 10240 faces is what you should see. Â Triangulating this model should not matter to Buldozer. But now sharpen all edge, and note that buldozer stops drawing the model.

ST coord errors (both causes, degenerated triangles and stretched mapping) are only a problem for drawing normal maps. Â Such errors prevent the normal map from being displayed on that particular bad face. Â I was told there is no performance problem if you leave ST coord errors in your model. Â If you have no normal maps, there is no reason to worry about them at all. Â If you have normal maps, then I guess you only have to worry if you see visual problems. Both errors indicate poor modeling/mapping though, so I usually check new models during the mapping phase to make sure I don't have any problems or to correct them while I'm doing mapping anyway. It's pretty crazy to try fixing some of the old OFP imports.

External dependencies are just for information. You need to edit the RVMAT which uses to that external dependency (the AS map is defined by a path in the RVMAT file).