On Thu, Apr 29, 2010 at 9:55 PM, Kai Sterker <kai.ster...@gmail.com> wrote:
> Also thought a bit about the rendering bug itself. The renderer is > written with the assumption that there is no overlap between objects, > as if they'd be Lego bricks. > > However, in the two instances above, overlap does occur. With the > doorway, the character moves through the wall. The collision > information lets him, but the renderer uses a simpler bounding box and > so character and doorframe intersect from the renderers point of view. I fixed this issue in the renderer. It was a bit different from the the one below, however, so one more to go: > Similar with walking on the roof. It is sloped as far as the collision > information is concerned, but for the renderer it looks like the > character is half-sunken into the roof. I'd really like to come up with an algorithm that can check which of the given cubes is rendered in front/behind the other, given our specific perspective. But so far I didn't really come up with something that worked reliably. For now I just improved the documentation of the current implementation a little. Still thinking about a more generic solution, at least for the case where both cubes intersect. Of course, my hope is that a generic solution for that case will be able to handle the other cases as well. Ideas welcome. One thing I already tried -- and which didn't work -- was to compare each cubes distance to the camera plane. But the problem was that a very large cube can be nearer than a small cube in front of the large one. Kai _______________________________________________ Adonthell-devel mailing list Adonthell-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/adonthell-devel
