> > >Hi.
> > >Just want to confirm if it's my video setup or the
> > >game.
...
> > >a large green polygon floating over the track, with
> > >shadow. It goes when I get roughly back on the
> > >racing line.
...
> I've seen this several times particulary when I've just left
> the track to take a detour via the grass, as I seem to manage at
> that corner 1 lap in 3! It seems surprising that this wasn't
> noticed in testing, unless it's an error that has crept in
> during duplication?
It's not a bug per se. Rather it is a discrepancy of the
3D engine that they have developed. In order for a 3D engine
to be quick it cannot calculate everything to the nth decimal
so to speak, and hence there will be cosmetic errors. Usually
that is most noticeable when polygons are not properly displayed.
The culprit is usually the algorithm that handles the sorting
of the polygons. Accuracy is more or less inversely proportional
to the speed of the algorithm. So that's why Crammond and Co must
go with inaccuracy and consequently cosmetic imperfection.
Actually a perfect sorting algorithm is very hard to come by.
And that's why you can see similar oddities in almost every 3D
game that is one the market, it is just that it is a lot more
noticeable in certain 3D games, eg. GP2 and ICR2.
One remedy is to use Z-buffering(here the Z-axis is perpendicular
to the face of the screen).
You have one Z-buffer and one frame buffer(the frame that will be
put on screen once all polygons in the frame have been processed).
Without getting technical, an algorithm has to calculate the X, Y,
and Z value of each pixel in a polygon. Then another algorithm
will compare this Z value with the one at coordinate (X,Y) in
the Z-buffer. If the current Z value is smaller, ie closer to you,
the algorithm will store the new Z value in the Z-buffer and store
the color of that pixel in the frame buffer. But if our current
Z value is larger, ie further away from you, this pixel is discarded,
ie not stored because it isn't visible since there is another pixel
in that same 2D spot that is closer to us, and the next pixel of the
polygon will be computed.
Suffice to say that Z-Buffering takes a lot more time(and memory)
than sort the polygons and then fill them or texture them.
But there will be no overlapping polygons.
A normal sorting algorithm will just have to sort each polygon,
usually by its middle Z-coordinate, and then fill or texture it.
Much faster but overlapping is bound to occur but actually
surprisingly seldom compared to all of the sorting that is being
done. That's why developers usually stick to plain polygon sorting.
Btw some of the new 3D accelerators chip sets will do Z-buffering
in hardware and hence it will outperform software sorting in
relatively low resolutions. But hardware sorting will be even faster...
The bottom line is that in games 100% accuracy really isn't
required and hence many developers will stick to normal sorting.
But with Z-buffering comes many other advantages, especially with
light sourcing and ray tracing so we will get to see games that
do that in real time through hardware in the not so distant future.
Maybe in GP3 or ICR3 or NASCAR III? :-)
--
--- Terje Wold Johansen
--- http://www.ifi.uio.no/~terjjo/
--- "I am your inferior superior." O.W.