1.31.28 disappering trees. #3806

[zaltor]

OS:Vista 64

CPU:Phenom II 985 3.4

Ram:6G DDR2@ 800mhz

GPU:2x 3870 crossfire 10.2

noticed at slight angles trees were dissappering.

At first there are trees,

Just a slight turn and they are gone......

[AHWULF]

Beavers.

[VICTARUS]

OS: XP 64

CPU: Phenom 9950 Quad-Core

Ram: 4G DDR3

GPU: GeForce 9800 GT

1920x1200

Had the same issue in the same town -- Malmedy -- but significantly worse: Facing an ~45 degree arc from west to south caused some foliage to disappear. The foliage always seemed to be grouped together -- a line of trees, all of the grass/bushes in an area -- and foliage elsewhere would remain. Moving around without rotating had no apparent effect, but I only moved around a little on foot, so it may have an effect over larger distances. The shadows remained and collision was still possible.

I couldn't reproduce this in all locations: I only successfully tried the two towns next to Malmedy (Stavelot and St. Vith) and, interestingly, the arcs all pointed towards the forest adjacent to them: A ~10 degree arc in Stavelot ESE and another ~10 degree arc to the NE in St. Vith.

A different FOV seemed to change size of the arc: Zooming in with the rifle shrunk the arc slightly, and using the binoculars got rid of it completely.

Additionally, while facing south in St. Vith and rotating left/counter-clockwise, a few of the trees near the right edge of the screen were culled a little before they should have been.

[Linnon]

Found the same issue at Nettersheim South Ab. several trees inside the AB (NW corner) as well as many bushes just outside the AB to the NW. (Tested in 1.31.27)

[AHWULF]

I wonder if the tree/bush clumps that have this issue are always the same? Best thing is to take a screenie like you did with the lat/lon in every place you see this. It could be certain trees or clumps are missing something.

[mcketten]

I fraps'd this in malmedy offline:

9MB4UTx4v2s

Athlon X250 3.0 OC to 3.3

nVidia GTS250 1GB running 2nd to latest drivers (cuz the latest were killing cards)

4gb RAM

Win7 64bit

Edited March 6, 2010 by Mcketten

[makrel]

Confirmed.

Got this alot in 1.31.1.28 yesterday in Stavelot area as well (around the Spa track). Trees suddenly popping out.

OS: XP 64

CPU: AMD FX-57 Single core

Ram: 2G DDR SD ram

GPU: GeForce 9600 GT

1600x1200

[mcketten]

So far it seems to be only nVidia users reporting this - possibly a driver issue?

[GOPHUR]

Just ticketed this yesterday. #3806

[VICTARUS]

So far it seems to be only nVidia users reporting this - possibly a driver issue?

The first report is an ATI actually, though all of them so far do have:

• 64 Bit OS

• AMD Processor

[mcketten]

The first report is an ATI actually, though all of them so far do have:

• 64 Bit OS

• AMD Processor

doh, i mixed him and 2nd one up

[VICTARUS]

I'm guessing here, but...

The clipping for the non-static visuals in a cell (Is cell right? Whatever the squares on the map are) is done based on a bounding sphere. For whatever reason, that sphere's center is always at sea level.

• The "hole" is always pointed at one of the corners of the cells.
  
• In Malmedy (for example's sake), the hole starts about 150m out and grows as the corner is approached.
  
• The shape of the hole is roughly a curved diamond with the widest point below the horizon.
  
• Spawned in a town on a river and couldn't reproduce. Drove south to higher terrain and could reproduce, but at far less than 150m.
  

[VICTARUS]

I'm at a bit of a loss to explain why it doesn't happen on every machine. I'm inclined to consider a floating-point precision issue, and what comes to mind is the 80-bit registers used by X87 instructions and some possible problem with AMD's implementation. (Even with SSE2 enabled there are still X87 instructions in there -- I even checked the executable just to be sure.)

Unfortunately, I couldn't find anything that said there were any problems with AMD's implementation to confirm/deny this. Then again, I couldn't really find much in the way of details on AMD's chips to begin with, at least the kind I was looking for. I couldn't get a small test program to run differently with x87 versus SSE2, but that could be any number of things -- my own lack of understanding, compiler difficulties, etc. -- and I don't have an Intel machine handy to compare to.

...yes, I'm obsessive. So what?

[GOPHUR]

Happening on my XP32 Core2Duo as well.

[VICTARUS]

Well that breaks the common thread...

A temporary hack could be to increase the sphere size and/or raise it a bit (again, assuming my initial implementation assumption is right): It shouldn't really hurt performance (occasionally a cell will be looked at for rendering a few degrees sooner that it would be otherwise) and I imagine it should be easy enough to do. Of course, an ideal solution would be to have the spheres have their height based on the terrain's average height and have them be a little more fine-grained (I don't think the tallest item in a cell is ever as large as the cell's maximum radius), but I'm guessing that would take more work than it's worth at the moment.

I'm still somewhat baffled at what could be causing it on some machines and not others, though, except for some slightly non-conforming hardware or the like -- I can't come up with a nice common thing to correct for, though. The hole being smaller with a larger FOV/distance from the corner combined with its shape definitely points to a bounding sphere; that distance being attached to altitude and it's being below the higher-altitude horizon points me to that sphere being centered at sea-level; and this not appearing on all machines (apparently) combined with being towards the edge of the sphere, as well as the small-large-small pattern with an increasing FOV, points me at some sort of floating-point issue.

I'm thinking that maybe this *is* an issue on all machines since I haven't seen any "Nope, not seeing this in X looking Y from point Z" kind of reports -- it's more than possible to not run into it if you're not looking and/or in the right spot, at least since this is a beta test and not the actual game -- in which case this is really straightforward: The bounding isn't considering high-altitude terrain, fix it. The FOV thing still *kind-of* points at a floating-point thing, but at least it's not hardware/OS-dependent. I like that kind of bug more.

[macdr50]

Just to add my experience. I have an AMD Athalonx2 cpu and a Gforce 8800. On the Thursday night test (1st part) I believe we were attacking Tourn, as I traversed my tank gunsight trees and bushes at all distances would disappear on the trailing side and appear on the advancing side. The affect kept pace with my gunsight speed and reversed as I changed direction. I reported it to the GM. I also noted it on the \all remarking that I assumed the other side saw the trees even if I didn't or that would make me a sitting duck.

[lutorm]

I'm at a bit of a loss to explain why it doesn't happen on every machine. I'm inclined to consider a floating-point precision issue, and what comes to mind is the 80-bit registers used by X87 instructions and some possible problem with AMD's implementation. (Even with SSE2 enabled there are still X87 instructions in there -- I even checked the executable just to be sure.)

Unfortunately, I couldn't find anything that said there were any problems with AMD's implementation to confirm/deny this. Then again, I couldn't really find much in the way of details on AMD's chips to begin with, at least the kind I was looking for. I couldn't get a small test program to run differently with x87 versus SSE2, but that could be any number of things -- my own lack of understanding, compiler difficulties, etc. -- and I don't have an Intel machine handy to compare to.

...yes, I'm obsessive. So what?

If it was a floating point hardware bug, I'm sure bigger and more important things than BE would have crashed and we would have heard about it. If it's a bug, I'll bet my life it's a software one.

[VICTARUS]

If it was a floating point hardware bug' date=' I'm sure bigger and more important things than BE would have crashed and we would have heard about it.[/quote']

I meant slight differences in implementation, not results that are completely nonsensical: One returns 4.0069234 to a long string of operations, the other returns 4.0069232. No, this would probably not lead to rampant crashing and chaos; just subtle bugs when numbers get really big/small (which is an issue with or without differing hardware, honestly; it's just the subtle bugs are more consistent).

Of course, if this is reproducible on every machine as I suspect, then the point is moot anyways (although I admittedly should have confirmed that someone *wasn't* getting the bug before ruling out the chance that they just hadn't reported/seen it yet).