On Wed, Oct 29, 2008 at 11:47 PM, Kai Sterker <[EMAIL PROTECTED]> wrote:
> However, it turns out that it isn't perfect either. There's something
> I observed today, that might offer a way forward: with our isometric
> view, I chose a camera plane whose normal vector is (0, -1, -1). It
> appears to give best results when sorting flat objects against
> non-flat ones.
>
> I then tried the normal vector (0, -1, 0) and it seems to perfectly
> sort non-flat tiles, whereas (0, 0, -1) works perfectly for flat ones.
Going through the algorithm, it appears that using a normal vector of
(0, -1, 0) boils down to cameraPos.y() - objPos.y(). (0, 0, -1) yields
cameraPos.z() - objPos.z(). Which makes perfect sense if you think
about it. So to sort flat objects for example we'd do
cameraPos.y() - obj_1_Pos.y() > cameraPos.y() - obj_2_Pos.y()
Which effectively is the same as
obj_1_Pos.y() < obj_2_Pos.y().
Persuing that approach, I'd try to use two render-queues. One
containing all flat objects, the other all non-flats. Each of them
would be sorted similar to the above:
if (obj_1_Pos.y() == obj_2_Pos.y()) obj_1_Pos.x()) < obj_2_Pos.x()
return obj_1_Pos.y() < obj_2_Pos.y();
For non-flat you'd check the z() position instead of y().
Then, for rendering we'd iterate over both queues and compare the
objects. Since each queue is sorted in itself from left to right, top
to bottom, it should only ever be necessary to compare the objects the
iterator points to.
In regard to non-solid objects intersecting with solid ones (see
http://lists.nongnu.org/archive/html/adonthell-devel/2008-04/msg00014.html),
we'd also only ever had to check the current iterator positions. If
we'd find an overlap, we draw part of the non-solid object, then the
solid object from the second queue and finally continue to compare the
remainder of the non-solid object against the next object from the
second queue.
Not sure if there is a catch somewhere in there without doing the
actual code, but seeing how all the approaches at having one queue and
sort that failed, this should be at least worth trying.
Again, any further suggestions are welcome! Even if they don't lead to
an immediate solution, they help to keep my motivation up :-).
Kai
_______________________________________________
Adonthell-devel mailing list
Adonthell-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/adonthell-devel
