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).

Histograms explain a lot too. Note especially that I didn't burn out any highights, though the sky was already blown out. All those nice textures in the mid range are still intact, defined, just compressed in the higher end of the histogram.

Nice pics guys, looks like a very interesting trip Tovarish! Shadow, Band of Brothers post does something like push all the midrange values up into high key, while also deepening some of the shadows, clipping sometimes into full black. Â The effect is intense contrast that mimics old footage a bit. Using Tovarish's nice monument photo:

P:\ is correct for texture path. Use TGA instead of GIF and it should work fine.

A reinstallation wont help since I think the texture was not included in the install. Instead of restoring the missing texture, it's better to just turn the option off. The only reason you see an error message now is because hte option is turned on. See my post above for instructions on turing off wireframe mode for buldozer.

If your buldozer starts up and looks like an ARMA menu screen, you didn't correctly use the -buldozer switch in your External Viewer path (check spelling, one L only) If you get an error about wireframe texture missing, it's because you have an option turned on in Oxygen's viewer menu (View > Viewers > Buldoser > Show Wireframe). Turn that option off. It is not true wireframe rendering, but uses a special texture to show what looks like wireframe. I guess your install is missing that texture file.

Because I don't work directly with BIS right now and my Czech isn't perfect ;-)

You shouldn't need to use any such named properties, because default behaviour is to use stencil shadows from SV LODs. At some distance, I think the engine will always switch to shadow mapping (the blurry kind) because only this type of shadow can be faded, and all shadows fade away in the distance. That's how I understood it. The only named property that should always be used is "LODNoShadow=1" on all visual LODs which are >400 faces. Default behaviour should be: *Use high detail SV lod to draw stencil shadow *At distance use lower detail SV lod to draw stencil shadow *At greater distance, use last or lower visual lods for shadow map source, and start to fade that shadow away.

rudimentary, maybe. Â I would say "there are far more complicated tools that can handle UV mapping with a lot more buttons" Â nice work though, i like to see these less common russian guns. hmm.. PYa, Gyurza, APS, 9A91, PSS, SVU-A...

Was just a shot in the dark, had a similar problem here recently. Haven't had a close look at O2 PE.

pal2pac.dll may be missing from the install, in o2's root directory. Try to copy it over from o2light.