On Tuesday 15 February 2005 18:44, Lourens Veen wrote:
> On Tuesday 15 February 2005 23:47, I wrote:
> > At this point I'm fretting more about DDA precision than the
> > perspective divide. I seriously doubt we'll get stable results
> > stepping across the whole screen with 16 bit precision. I'm
> > mulling over a couple of suggestions, short of adding more bits.
>
> ...At any rate, could we assume a maximum of 2048x1536 for the
> resolution? That means 11 bits for integer screen coordinates, so
> we'd have an 11.5 split if we did fixed point (and floating point
> just doesn't make sense to me here really, comments?).
Floating point makes a whole lot of sense here because we don't have
much control over the input parameters, which can vary over wide
ranges. The W divide introduces a further, large degree of variation
for new and far objects. A typical nasty case is a viewpoint near a
huge vertical plane running far into the distance, i.e., looking along
the side of a building.
> That means
> that if the span is larger than 32 pixels, we get in trouble. In
> fact, we'd need 11.11 probably to get it perfectly right. Which means
> 22 bits adders :-(.
You can get in trouble way before hitting a full pixel error in the
geometry. For example, the jaggies may start doing wild things in
animation instead of crawling along the edges nicely like they are
supposed to.
> So we need other solutions. Something Bresenham-like, storing the
> dIdX value as a rational number,
Bresenham has a few problem for this application. It doesn't drop out a
nice, usable error term for the horizontal corrections in vertical
rasterization. It needs careful setup to get the jaggies in the right
place as opposed to centering them over the span. It needs extra
arithmetic to handle a transition rate greater than one.
> and what if we drew the span from
> both sides to cut the error in half (ie, we do two pixels at a time,
> but not next to one another, but one starting at the left side of the
> span and the other on the right side)?
This problem needs stronger medicine than just cutting the damage in
half. Also, meeting in the middle makes any cumulative error easy to
see. The tears down the middle of triangles will crawl around the
screen in a distracting way. And it's not going to be friendly to the
DRAM interface.
> Just some thoughts.
Three options that seem viable to me are:
1) Correct each interpolant on the fly using a single multiplier in a
round robin.
2) Chop up big geometry in the driver vertically and horizontally into
bite size chunks.
3) More bits, just for the interpolants.
The second of these seems the most pragmatic since it can be offloaded
to the host, saving gates and Timothy cycles. The extra work would
level out nicely because larger triangles incur most of the penalty,
and there should be fewer of them. For best visual stability, the
clipping planes would form a rectangular mesh in screen space. Note
that this means small triangles do not necessarily escape intact,
however they are more likely to.
> Incidentally, these differentials are calculated
> on the host, not the card, right?
Most probably off-card because we ran out of multipliers some time ago.
The problem with that is, it really bulks up the DMA stream, and PCI
bandwidth is already tight. This is probably just a case of grin and
bear it.
Regards,
Daniel
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
