|
From: Dair G. <da...@re...> - 2004-08-08 09:39:37
|
James W. Walker wrote: >I've been doing some experimentation on ways of doing depth sorting of=20 >transparent triangles. The choice of algorithms comes down to one of=20 >those classic tradeoffs: do you want the job done right or do you want=20 >it done right now? But it seems clear that we can do better than what=20 >we have now. See also bug 895117: that's the case that originally raised this issue. >1. current Quesa comparison method, qsort >2. centroid comparison, qsort >3. barycentric comparison, selection sort after centroid qsort Is the centroid method just taking the center in z of the two triangles and comparing? If so that's actually what we used to do, but you changed it last year... :-) If look go back to revs 1.9/1.10/1.11 of IRTransparent.c we have: 1.9 "Centroid" (assuming above is true) 1.10 ifdef'd plane equation test 1.11 final plane equation test Unfortunately I can't find the mail that started that change in motion, but I can remember some discussion about how the centroid method wasn't providing the best results and hence we added the more complex test for triangles. There are some more notes in a URL attached to 895117: I tried that approach, but it didn't help with the box test unfortunately. >Comments? =46irstly, nice test app. :-) 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. 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. If it's not the same as 1.9, can you post a snippet showing what it does for the overlapping extents case? -dair ___________________________________________________ mailto:dair+refnum.com http://www.refnum.com/ |