Re: [Algorithms] Bicubic normals for a bicubic world

[John S. <jse...@ho...>]

Actually, I hadn't thought of simply rejecting whole patches that are
backfacing, and leaving the rest up to the driver... That may be the wisest
solution. Thanks.

I am "cheating" for different tesselation amounts right now, and the results
are very good. With the algorithm I've written, the edge match up almost
exactly, so the slim triangles are very slim indeed. They simply cover tiny
holes that would show up due to floating-point inaccuracies.

And hey, if your ranting gives me more insight into what I'm doing, go right
ahead and rant! ;-)

John Sensebe
jse...@ho...
Quantum mechanics is God's way of ensuring that we never really know what's
going on.

Check out http://members.home.com/jsensebe to see prophecies for the coming
Millennium!


----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: <gda...@li...>
Sent: Saturday, August 12, 2000 2:42 PM
Subject: RE: [Algorithms] Bicubic normals for a bicubic world


> Hmmmm... OK. Tricky.
>
> Incidentally, I would question whether you want to bother with BFC of
> subpatches. I would go with the philosophy that since most patches will be
> wholly rejected or wholly accepted, the borderline cases are few in
number.
> However, if you're doing a BFC calculation + test per sub-patch, that
seems
> like a fair amount of work for _all_ visible patches, just to save a bit
on
> borderline patches.
>
> My instincts would be to BFC a top-level patch, then set up your
Difference
> Engine to the required tesselation level and just draw the whole thing,
> letting the hardware do tri-level BFC.
>
> The edges where different levels of tesselation meet require a bit of
> thought. "Cheating" by simply stitching them together with slim tris after
> drawing each patch at different levels is a possible option, and very
quick
> (it's a second forward-difference engine, but only in one direction, along
> the crease). But you tend to get lighting differences between the two
> patches, which can be visible.
>
> You can also special-case the edges of the patch drawer so that it fans
the
> edge tris to match adjacent patches, which looks quite good. And it's
pretty
> good for speed, since you can do this by shrinking the full speed
> tesselation by one on each edge that needs higher tesselation (fewer than
> half the edges of the scene will need extra fanning(*)), then doing the
> fanned edges with special case (but exceeding similar-looking) code.
>
> Anyway, there's probably some very good reason why you're doing it
> recursively, so I've probably just been ranting. Sorry!
>
> Tom Forsyth - Muckyfoot bloke.
> Whizzing and pasting and pooting through the day.
>
> (*) Ah - almost true. True if you don't BFC the patches :-) Close enough
for
> performance considerations though.
>