Re: depth sorting (bug 989156)

[James W. W. <os...@jw...>]

On Aug 8, 2004, at 2:39 AM, Dair Grant wrote:

> See also bug 895117: that's the case that originally raised this issue.

I can't find that bug.  I've set SourceForge to browse bugs with 
Assignee, Status, Category, and Group all set to Any, but the bug 
numbers jump from 895106 to 900672.

> Is the centroid method just taking the center in z of the two triangles
> and comparing?

What we used to do was not exactly the centroid method.  We took the 
average of the maximum and minimum z values, which is not equal to the 
average of the 3 z values of the vertices.  However I wouldn't be 
surprised if the results were pretty much the same.

> If so that's actually what we used to do, but you changed
> it last year... :-)

I was hoping nobody would notice that. :-)  Clearly I didn't do enough 
testing back then.  If you look at the case of a single box in my test 
app, then arguably the current Quesa method is better than the centroid 
method.  But once you get to two boxes, it's a different story.

> Firstly, nice test app. :-)

Thanks.

> I think the problem does come down to a tradeoff: even more so than you
> describe here, as strictly speaking interpenetrating triangles need to
> be split into sub-triangles if they're to be sorted correctly.

True.

> Most interactive scene graphs don't bother going that far, and I think
> whatever choice we make is going to have to have some trade off. The
> centroid case definitely does improve these boxes, but assuming it's 
> the
> same as 1.9 then we would presumably make some other case worse.

Yep, such as a single box.

> If it's not the same as 1.9, can you post a snippet showing what it 
> does
> for the overlapping extents case?

I'm not sure what you mean by overlapping extents.

--
<http://www.jwwalker.com/>