From: Andreas K. <and...@we...> - 2004-10-13 07:44:24
|
Hi! > I think it would be very hard (and confusing) to subdivide the mesh in a > way that it appears as several objects to the renderer. This approach would > let the global hmaker do all the work automatically, but I expect it would > be really nasty to write. Yes, you're right. The implementation would be a bit nasty... > It's probably better to keep the whole mesh in a single object and build > a sort of octtree (or similar) inside it, so that only a small part of the > triangles need to be tested. I'll check if I could re-use the hmaker for this purpose nethertheless. I could make the triangle mesh to be one object for the renderer but build my own object/triangle hierachy inside the triangle mesh (like you suggest). Is this would be quite similar to what hmaker does, so the code could be re-used (although the interface might have to change a bit for this, maybe make it a template class). BTW: In the paper I mentioned some time ago (XU Zhi-Yuan, et al: An Efficient Rejection Test for Ray/Triangle Mesh Intersection) they use a different approach. They have a fast rejection test for ray/triangle intesection which is based on the following fact: Given any plane the ray is part of. A triangle then cannot intersect with the ray, if all its 3 vertices lie on the same side of the a plane. (I plan to use this rejection test as well). But they do not build a 3D object hierachy like we discuss here. Instead, they build a quad-tree for the vertices (as seen from the observer), so that the position of vertices relative to the plane can the determined quickly. However, this approach only works for primary rays and only if the primary rays really come from the same point in space as far as I understood it (which is not the case if e.g. you do focal blurring). Therefore I do not want to use this approach (it would be a nasty to implement anyway, since the object needs to have information about the observer) but go the 3D hierachy way. Regards, Andreas |