FI - Fix Graphics drawing in the distance and Crossfire Use

[Silkwraith]

Should one go through the pictures posted - one would easily notice that the Graphics Engine fails to draw objects slightly in the distance considerably ruining ones immersion in the fight. I hope that this shall be corrected in the new Graphics Engine soon to be released with Fortress Italy.

Another matter which I would like to highlight and hopefully corrected is the possibilty of having ATI Crossfire working properly

[MikeyD]

I don't follow. Doesn't do what, exctly? You're not talking about the ability to toggle trees on and off so you can view the terrain, are you?

[Wicky]

I think's he's on about the foreground stripping of foliage :confused: so one can see what's immediately below.

I herby demand Battlefront should instead sell X-Ray specs!

[Bil Hardenberger]

I think he's talking about the fact that some terrain items don't draw at farther distances and textures do not blend as they go into the far background of a map.

[Silkwraith]

That is precisley what I mean Hardenberger, thanks - I hope they rectify this matter

[Childress]

Isn't that determined by the quality of the video card?

[c3k]

Silkwraith,

Could you download one of the attached pictures and use paint (or something similar) to show precisely what you mean?

Regarding Crossfire: I'm not a programmer, just curious about what isn't working with your setup.

Thanks,

Ken

[Wicky]

BF: Fix that graphics drawing in the near distance ..its ugly and ruins the game

http://www.battlefront.com/community/showthread.php?t=104896&page=10

:confused::confused:

near distance = foreground (CM deliberately strips foliage so players can see & command their pixeltroopen)

far distance = towards horizon (renders lower res models so graphics cards don't melt under the strain of displaying a half-decent frame rate)

[BFCElvis]

Should one go through the pictures posted - one would easily notice that the Graphics Engine fails to draw objects slightly in the distance considerably ruining ones immersion in the fight. I hope that this shall be corrected in the new Graphics Engine soon to be released with Fortress Italy.

This is from the list of new features with v2.0:

- Improved rendering. Normal and Bump mapping allows for more texture detail while using less system resources and improving the pressure on framerates.

http://www.battlefront.com/index.php?option=com_content&task=blogcategory&id=297&Itemid=507

You should notice an improvement.

[Bil Hardenberger]

It could be my video card that is the culprit here, and not the game. Check ND's AAR thread.. he might have some images that do not show the degradation mine shows.

Bil

[Silkwraith]

I do not think that its your videocard. I have to very good video cards in my PC and I notice this as well on my PC.

I hope BF fixes this matter - it would be greatif they do

Thanks for your patience and your reviews, really appreciated. This addon should be awsome

[Offshoot]

This is from the list of new features with v2.0:

http://www.battlefront.com/index.php?option=com_content&task=blogcategory&id=297&Itemid=507

You should notice an improvement.

Normal mapping won't automatically improve rendering of distant terrain - likely it won't even be used for this. Substituting in low-resolution textures for distant terrain and objects is a standard for computer games (called mipmapping), though CM's routine does seem to be quite 'aggressive'. It's like it is full high res or full low res without any in-between, so you get quite harsh differences in the rendered view. Does anyone know if there are game settings anywhere to fiddle with mipmapping?

[c3k]

Silkwraith,

A language issue: "near distance" has been interpreted as meaning "foreground", at least by me.

It seems you mean "distance", but not necessarily all the way distant. I would suggest that you mean "starting at a medium distance and extending to the far distance". Forgive me if that's not what you meant. (I saw what you circled in the AAR thread. What I just wrote corresponds to the circles. As well, let's keep the AAR thread purely devoted to the actual action, not other issues.)

The distance at which LOD's kick in does seem too early. LOD = Level of Detail: a totally different piece of artwork depicting the same reality. I do not know a thing about why or when they kick in. I do know that LOD's kick in earlier with weaker graphics cards. I would WISH that they do not kick in at all.

There was criticism of this in the past. The actual LOD pixel numbers were posted. If BF.C did NOT reduce graphical fidelity to a lower level through the use of LOD's, the game would bring a Cray to its knees. They are needed. The question is, can they be pushed further back, or changed to ameliorate the jarring difference between "regular" graphics and LOD graphics?

I don't know.

I do know that BF.C is responsive to CONSTRUCTIVE criticism backed up by data. I also know that BF.C has very rigid priorities and that "eye candy" comes in a distant place compared with many of the ballistics and behavior issues. "Eye candy" is a bit perjorative, but I do not mean to take away from the importance of a smoothly blended 3D view - which does not occur right now.

Obviously, it is more important that the penetration of APDS 6 pounder shot vs. face-hardened Panther glacis armor, while the Panther is on a slope, angled away from the gun, but green and scared, is more important than when a road looks smooth.

I don't know when BF.C will have the resources to address this.

[Ranger33]

Yeah, pretty sure this is one of those things they wish was better, but they just don't have the resources to make it happen all at once. Each version of the engine seems to run and look better though, just look at the previously mentioned improvements in rendering coming in the 2.0 upgrade.

I have a PC that can run Crysis maxed out, with 2xHD 5770's, 12 GB RAM, i7 quad core, yadda yadda, but has to leave CMBN on the medium settings. Setting it to the higher settings actually makes it look worse because the engine just doesn't scale very well.

[Ron]

Yeah I'm not getting the criticism either. From the majority of screenshots, it appears the opposite is true. The LOD is definitely improved for the near distance and there is a much more natural transition as the details change. The drastic cutoff present in CMBN is no longer there it seems. Check out some of the QB screens posted by sdp, awesome stuff.

[Bil Hardenberger]

oops, wrong thread.

[Battlefront.com]

This is the age old question for us... how much of our limited resources do we spend on improving the game, how much do we spend on improving the look of the game. It always has to be a choice because the number of game things you guys want is endless (literally), so if we spend 2 months redoing graphics stuff then that's 2 months worth of game features you don't get. Would be wonderful if the market was big enough so we could have a dozen programmers and several dozen artists like the big games have. But that's never going to happen.

What we can do is work on things in stages. We already doubled our programming staff (1 x 2 = 2 ) partly to improve the graphics without sacrificing game features, partly so we can do more than one game every couple of years. The history so far shows how well we're doing over time. Anybody that doubts that can boot up Shock Force 1.0 and see for themselves

Version 2.0 addresses some huge underlying issues that affect framerates. With those things now addressed we can start to look at how much of the newly freed up resources can be used for other aspects of the game. Terrain rendering/blending is top of our list for Version 3.0.

Steve

[Bil Hardenberger]

Steve, Mip Mapping is the answer.. it's such a simple solution I am really surprised it hasn't been adopted yet in CM. Of course I say simple without really knowing what would need to go into the programming side to wedge the code for them into CM's graphic engine. That's Phil's job.

http://archive.gamedev.net/archive/reference/articles/article1233.html

Bil

[sburke]

What we can do is work on things in stages. We already doubled our programming staff (1 x 2 = 2 ) partly to improve the graphics without sacrificing game features, partly so we can do more than one game every couple of years. The history so far shows how well we're doing over time. Anybody that doubts that can boot up Shock Force 1.0 and see for themselves

Steve

Really? 1 x 2=2 as an example of doubling your staff? Your high school (and maybe your elementary school) math teacher would be embarrassed and would likely make you go stand in the corner with that pointy cap. If you were trying to show the number of man hours they goof off during lunch sure. Okay maybe that would be 2.5 x 2 = 5 We all know how the siestas go at BF while taking in the views from the yacht. Now 1+1 = 2 that would be doubling your staff.

Okay Phill you can stop rolling your eyes behind his back, just be glad he isn't in charge of payroll. oh he is? Sorry.

[Gen Von Television]

Mip Mapping is the answer.

I'm not that sure about it: certainly it was born ages ago so to eventually solve the RAM load on old systems with poor graphics and limited video cards.

Personally I always disable the mipmaps in any 'game' or sim that has that option possible, since the visuals are very much degraded...

[Bil Hardenberger]

I'm not that sure about it: certainly it was born ages ago so to eventually solve the RAM load on old systems with poor graphics and limited video cards.

Personally I always disable the mipmaps in any 'game' or sim that has that option possible, since the visuals are very much degraded...

Well, by doing that you are then using the largest texture across the entire map, even in the distance where the detail in the larger maps is not needed. The purpose of the Mipmaps is to use less and less graphic resources whenever possible without sacrificing the visual quality of the rendered map, model, etc.

Bil

[Battlefront.com]

Steve, Mip Mapping is the answer.. it's such a simple solution I am really surprised it hasn't been adopted yet in CM.

If the answer seems so obviously simple... question the answer No, it's not that simple. We know what the answer actually is and it's going to take a pretty good chunk of development time to implement. Fairly straight forward, thankfully, but time consuming none-the less. We had hoped to get it into Version 2.0, however we just didn't have the time for it yet. In fact, as far as I know mip-mapping plays no role in it, but then again I've only a superficial understanding of what is involved. Plus, look at my math skills...

Really? 1 x 2=2 as an example of doubling your staff?

And this, kids, is why I stopped trying to program when I was in junior high school. Damned math just hurts my head

Steve

[Battlefront.com]

Well, by doing that you are then using the largest texture across the entire map, even in the distance where the detail in the larger maps is not needed. The purpose of the Mipmaps is to use less and less graphic resources whenever possible without sacrificing the visual quality of the rendered map, model, etc.

Which is why mipmaps don't help in this case. The reason details are being dropped is because we're cutting out polygons through LODs. The textures are irrelevant. The problems which arise come about for two reasons:

1. Action Spots are boiled down to a single texture instead of the multiple textures at closer distances. Hard edges are, therefore, unavoidable because we are now talking about squares and not organic shapes. A new rendering system is needed to make an on-the-fly blending of two (or more) terrain textures based on specific orientations.

2. Overlayed polygons (like roads, walls, etc.) are removed too close to the camera. This can be fixed right now by not removing them or removing them at a further distance. The problem until now has been the impact on framerate for retaining all those polygons.

In neither case does mipmapping come into play.

Steve

[Gen Von Television]

Besides, in theory mipmaps system should preserve the quality and lessen the load on graphic resources, but in practice in my experience it fails in the first instance.

The quality is not preserved at all.

[sburke]

You've mentioned now in a couple threads some of the things you guys are trying to work out in development both in graphics and the UI with a proposed target of version 3. (and thank you for those points, it really does peak the interest to see what the game may be like for Bulge/Bagration/Whatever CMSF2 will be called assuming they might come out running version 3).

One question and this one may be too early to say - how might this affect the unit modelling and therefore some of the mods? For example it is already a given that the mods for CM:BN will be outdated with the release of a MG module/version 2. Would it be your expectation they may be outdated again with the release of version 3 or is it too early to say on that one? Also a bit of self interest there as having to remake models at both version level releases has got to slow down the production line if even just a bit.

I think based on some of the commands visible in the UI shots in the AAR for example some of the scenarios already created will likely be tweaked with armored covered arcs and game play even PBEM will be impacted in existing scenarios (all of which is good news).