Re: [Algorithms] Bicubic normals for a bicubic world

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

OK, here's an update. I commented out the culling routines I had in the
recurvsive portion of my patch splitter and added some simple culling to the
patch setup routine and got a 40% drop in frame rate! Granted, the culling
routines I had weren't filling the bill and would have to be slower to be
correct, and my test data is optimal, consisting of spheres built from six
patches (like a cube).

Anyway, the problem with this seems to be that I've written my routine
specifically to build up the edges of objects to reduce faceting, so I end
up with a lot of "borderline" subpatches. So I either eat the loss in frame
rate, or I'm back to square one. :-(

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.
>