RE: [Algorithms] Bicubic normals for a bicubic world

[Tom F. <to...@mu...>]

I wasn't thinking of artifacts from any holes - they'll be fine - but of the
abrupt changes in lighting. I too started off cheating this way, but you
have a T-junction in terms of lighting shades, even if the actual few tiny
pixels in the T-junction are filled, and if your tesselation is not fine
enough, the eye can spot these changes in lighting. Which is why I moved to
fanning the edge tris - the lighting change is spread over the width of the
fan (which is usually a decent number of pixels, i.e. not 1), and it is far
less noticeable.

Tom Forsyth - Muckyfoot bloke.
Whizzing and pasting and pooting through the day.

P.S. John - we need to talk about that home page - that's going to get a
nomination from me on http://www.uglyinternet.com/ I'm afraid. Gotta be
cruel to be kind.

> -----Original Message-----
> From: John Sensebe [mailto:jse...@ho...]
> Sent: 12 August 2000 21:05
> To: gda...@li...
> Subject: Re: [Algorithms] Bicubic normals for a bicubic world
> 
> 
> 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.
> >
> 
> 
> 
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>