Hi Folks
ChrisHunt wrote:Paul, could you shed some light on the the incorrect mesh implementation of the two photo scenery players?
And also how this might affect performance?
My current concern (Okay obsession) is with the dreaded st st st stutters - does SP2 help?
Chris -
The issue was not implementing 'fraction bits',
which AFAIU generate the slope between two known elevations, (post points).
This results in a stepped terrain appearance,
which consists of more polys,
therefore is more processor intensive to display.
Put simply -
Think of your household stairs, (simplified as 10 steps, post points),
ground level, 10 risers, 9 treads, top level, == 21 polys
Now replace that with a ramp, (i.e. as if an IRL slope, with the same post points) -
ground level, 10 slopes, top level, == 12 polys
Now instead of a single planar surface,
think of a complex 3 dimensional hillside
comprising of gullies & ridges,
the number of polys increases again.
These example screenies are from a mesh I'd created, (nothing to do with either provider),
but the practise was exactly the same, i.e. compiled without fractionbits.
They probably show the resultant effect better,
with the sandy colour being the treads,
and the darker green colours, the risers.
This first shot is on a gentle relatively even slope -
This second shot is from a more complex surface -
If compiled correctly they would have been a gentle unstepped slope.
Depending on your flight level & config settings
AFAIK, the stutters have a number of causes.
At altitude, they're primarily caused by IO access stalling for the photo-tile mips.
At low-level its a combination of IO access to the photo-tile mips,
plus IO access for the mesh, then resolving the mesh complexity.
The faster you are flying, the more often the data is accessed.
SP2 addresses performance with FSX type photo-scenery, (as c/f FS8 style photo-scenery, e.g. Visualflight).
I'm hypothesising here,
but think SP2 is minimizing stalling by updating the IO request thread,
by discarding any calls for tiles which the viewport has 'overflown' before having been successfully updated.
Possibly also by prioritizing updating on the immediate area of the viewport, e.g. user a/c windscreen,
rather than the distant, and less frequently changing, low-level mips,
If I've understood correctly,
there may also be an additional issue with the 3rd party provider's photo-tile implementations.
However achieved,
it's definitely working better with SP2 for me.
The overly-complex mesh issue is their providers responsibility,
and at least one of them will be issuing a new disk to correct this.
Cross cultural cost differences
are I think primarily down to small volume localised marketing costs.
I 'decline to comment' on -
the moderating practises at a 3rd party site,
the expectations extrapolated by other persons,
or any potential merits in your other points raised.
To contextualize,
Vista shipped late,
DX10 shipped late,
DX10 hardware shipped late.
All of which had a direct knock on effect WRT SP2 development.
I will however say,
that given the issues involved,
plus the time constraints,
it was the only possible outcome.
HTH
ATB
Paul
