[fgsfds]

Presented in software only.
Make 2 masked walls with a gap between them. This is what happens when the center of a sprite is visible in this gap.

Attached thumbnail(s)

• 

Attached File(s)

•  bug.zip (443bytes)
  Number of downloads: 183

[Helixhorned]

Confirmed, this does not happen with Duke3D 1.5. I'll need to bisect this some time then, feel free to beat it to me if you want to get this fixed quicker.

[Gambini]

Really? We´ve been using ports so many years that I would have sweared it was an "original" problem.

I will make sure you fix it, posting in this thread every two hours

[Helixhorned]

And it's OLD, most likely going back to drawmasks() changes in r278. That's 2006.

[Plagman]

Hmm, so it was my sorting changes?

[Gambini]

Yeah now I remember some tests i did for a map in 2008 and taht there was a difference of how the masks were drawn between jonof and eduke.

[Helixhorned]

Plagman, on 18 March 2012 - 03:36 PM, said:

Hmm, so it was my sorting changes?

I haven't tried reverting them, but it's the most probable candidate in the range of revisions between builds 20060821_2 and 20060829, where the change happened.

[Plagman]

I think I was only considering the sprite point rather than the sprite plane when doing sprite/masks occlusion checks, so it would make sense that a case like that ended up messed up.

[fgsfds]

Still not fixed after 6 months.

[Gambini]

*cough*

[fgsfds]

bump

Attached thumbnail(s)

• 

[Helixhorned]

Alright, I made a change in r3700r3701 that fixes sprites wrongly drawing after masked walls if they are near the border of a masked wall but behind them (wrt the viewing position). I haven't tested whether this has any other adverse effects, but the issue is not specific to classic. If you make the masked wall transparent, with the same situation you'll see that the liztroop is not drawn where it overlaps with the wall. So... it is drawn after the wall, but depth testing throws out those fragments.

In pseudocode, drawing masks (masked walls and sprites) looks like this after sorting:

while (we have masked walls to draw)
{
    _point2d dot = <first point of the masked wall>;
    _point2d dot2 = <second point of the masked wall>;

    _equation maskeq = <plane between 1st and 2nd points>;

    // additional:
    _equation p1eq = <plane between cur. position and 1st point>;
    _equation p2eq = <plane between cur. position and 2nd point>;
    _point2d middle = <midpoint between 1st and 2nd points>;

    for (all sprites yet to draw)
    {
        _point2d spr = <position of sprite>;

        if (!sameside(maskeq, spr, pos) &&
                sameside(p1eq, middle, spr) &&
                sameside(p2eq, middle, spr))
        {
            <draw the sprite first>
        }
    }

    <draw the masked wall>
}

<draw the remaining sprites>

Plagman, what's the point of the two last terms in the conjunction?

[Fox]

I got some sprites disappearing out of nowhere bug. But I will look at it again later.

[Helixhorned]

I have to admit that I did something extraordinary stupid when "prettifying" some code in r3700. Please don't use synthesis r3701 and upgrade to r3704 when it gets built. Sorry!

[Helixhorned]

I'll continue discussion of the other maskwall/sprite drawing bug reported by Micky here in this thread. Contrary to what I said there, that one is present in Duke3D. Moreover, with the way mask drawing is structured now, you have the choice between one or another bug; you can't fix both!

The basic issue is this: masks (masked walls and sprites) are drawn after all solid geometry in Build. We have sorted masked walls separately and sprite separately, roughtly by distance. However, we don't have an ordering between the two classes. So what is done is that we start drawing masked walls, back-to-front, and before each maskwall, we check whether any sprites "behind" it need to be drawn. Here's a sketch:



The question is, what constitutes a sprite being "behind" a masked wall? In the current implementation, this is decided based on the map coordinates of the wall-points and only the position of the sprite. That is, neither the extent of the latter is not taken into account, nor how a sprite is shown in screen space with respect to the masked wall. Most cases are answered easily, but there's one case (behind the masked wall, outside of the 'cone' given by two rays from the player toward each wall-point) that can make sense this or that way. The following screenshots show how the two modes lead to one bug or the other. The numbers indicate the order in which the elements are drawn.



The bottom line is, without significant rethinking of mask drawing, we can't fix both bugs simultaneously. There are various possibilities that come to mind, but every one is a small project in its own right.

[Micky C]

Assuming that eventually the mask drawing system is going to be restructured, would it also be possible to fix all those clipping issues in classic where floor aligned sprites etc overlap each other depending on the viewing angle?

Edit: I agree with James, especially considering I've just created a new area with several aligned sprites and some masked walls, and the problem with the masked walls appearing in front of the sprites is even more obvious.

[Jblade]

I think on the scheme of things it would be better to go with leaving the sprite glitch in and fixing the mask wall bug rather than visa versa simply because in your example pic the maskwall showing through the sprite is far more noticable than the liztroop appearing through the mask walls (and to be fair I think the latter doesn't happen that often anyway apart from maskwall heavy usermaps)

[Helixhorned]

It's somewhat coincidental that the trooper seen through the gap turned out to look relatively benign. Here's another example showing what can happen if you subdivide the masked wall:



Really ugly! So, I think we have no choice but to think hard about solving it for both cases.

[Plagman]

I had code to do full, perfect sorting of masks and sprites (didn't resolve intersections, however). It was way too slow on MAZE.MAP, however. That fucking map...

[ToiletDuck64]

Helixhorned, on 18 January 2014 - 04:44 AM, said:

maskwall_drawing_modes.png

(edit: the thumbnail doesn't seem to show up in my post for some reason)

Hold on...I think there may be a separate problem there.
I don't know where those maps came from, so...how is the map in the upper comparison laid out? I'm assuming the square thing (sprite? surface? whatever the viewpoint is "standing on"?) is supposed to be in front of all five numbered things, and is directly in front of #3.
In the upper left, how is it getting drawn before the masked surface (#5), if it's in front of it? That may be a separate issue.

[Micky C]

Plagman, on 19 January 2014 - 01:42 PM, said:

I had code to do full, perfect sorting of masks and sprites (didn't resolve intersections, however). It was way too slow on MAZE.MAP, however. That fucking map...

Hold on, so some improved code already exists but is too slow for some maps? Would it be possible to implement this code as an option? That way those who want less clippy maps can have that, while still being able to use the original code in cases where speed is needed.

[Forge]

Plain Simple Garek, on 20 January 2014 - 05:46 AM, said:

Hold on, so some improved code already exists but is too slow for some maps? Would it be possible to implement this code as an option?

super.
something else for people to yowl about getting optimized

[Helixhorned]

ToiletDuck64, on 20 January 2014 - 03:23 AM, said:

In the upper left, how is it getting drawn before the masked surface (#5), if it's in front of it? That may be a separate issue.

It is a bit tricky indeed. In the upper left screenshot, drawing of mask #4 is preempted by the sprite, #3. This happens because that rightmost masked wall (when imagined as being continued) actually goes between the player and the sprite, and by the "always draw sprites at the other side of a masked wall" rule, the sprite comes first. As a consequence, the final drawing order is wrong with respect to the sprite and mask #5! But that's never considered, because when it's #5's turn to get drawn, the sprite is not in the set of candidates any more.

So, in this debugging view, whenever you see a sequence #n, #n+1 ... #n+i of sprites and then an #n+i+1 maskwall, it means that the sprites had to be drawn early because of the masked wall.

I'm attaching the missing test map, where the continuation of the offending maskwall is indicated by a (drawing-wise unrelated) red wall. Thanks to Plain Simple Garek (aka Micky C) for providing the map from which this one is obtained.

Attached File(s)

•  MICKY_maskbug.zip (1.79K)
  Number of downloads: 120

[Helixhorned]

Plagman, on 19 January 2014 - 01:42 PM, said:

I had code to do full, perfect sorting of masks and sprites (didn't resolve intersections, however). It was way too slow on MAZE.MAP, however. That fucking map...

The depth peeling code, right? It seems that one was only for the GL modes if not Polymer-only, whereas the issues here concern all renderers, but especially classic (more on that below). I took a very short glance and what I grasped is that it used framebuffer objects and some kind of pre-GLSL shading language (the one looking like some kind of assembly, which it probably also is).
Where's that map from, btw? It looks pretty useful for these purposes.
---

By the way: in which order masks are drawn is also an issue with the GL modes, but usually glitches like these go unnoticed because depth testing "hides" them. For that, the objects in question better be solid and opaque though; here's what can happen if they're not:



Exercise: explain why you see what you see. (Hint: currently, the GL modes use the other strategy, that is, draw sprtes behind masks early only if they're inside the 'cone'.)

[Plagman]

The depth peeling only went a limited amounts of layers; it did resolve intersections, however:



The code I'm talking about was just CPU sorting based on a tree of plane occlusions rather than trying to approximate depth or anything. It was actually the proper solution but performed horrendously slow.



For Polymer I'm considering doing away with trying to get the order right and just go with approximate order-independant transparency instead. Not quite additive blending, there exist better tradeoffs these days. We would need better hinting from the content side as to what needs to be drawn with blending on or off, however, which is something I've wanted to do for a long time anyway. Eg. always draw models with blending off, unless a surface is specifically marked as blended.

I'll leave the screenshot trivia for someone else, don't want to spoil it!

[Plagman]

And I have no idea where that map is nowadays. It was on a hard disk of mine that died. I didn't make it, I think TerminX sent it to me at some point.

[Helixhorned]

Interesting! For sorting masks the totally proper way, I was also thinking along the lines of calculating the "occludes" relation (to me it seems a DAG though, not a tree). Was that code ever committed or did you decide that it wasn't usable during development? Just wondering whether it was asymptotically inefficient or if it was OK (say, not much worse than O(N log N)), but too slow in practice. If the upper left number is an FPS count, 60 seems fairly reasonable after all, assuming there's room for "low-level" code optimizations.

Of course, for the two very specific problems at hand we may not need the "perfect" sorting algorithm if bad cases aren't likely to be practically relevant. So, the alternative I'm contemplating is just some well-placed hacks such as taking into account the extent of the sprite, as hinted earlier.

Plagman, on 21 January 2014 - 02:33 PM, said:

For Polymer I'm considering doing away with trying to get the order right (...)

That doesn't solve the issue of fragments wrongly thrown out by depth testing as with my screenshot though, unless I'm not getting the full picture.

Quote

I'll leave the screenshot trivia for someone else, don't want to spoil it!

Yeah, that "puzzle" was directed to users wishing to get some insight into how Build is on the inside. I figured you'd solve it in an instant.

Here's another one: in the past, people have requested "sloped sprites". Assuming a sprite is only drawn once per frame in its entirety, what's the problem with that?

[Hendricks266]

That's a thought: hooking pitch and roll up to sprites. There would have to be a separate mdflag involving billboarding however.

[Plagman]

I tried lots of different hacks or tweaks in the sorting over the years and there's always something that breaks in a map somewhere; I think some version of the brute force sorting made it to SVN (probably very close to the origin of the repo) at some point because there were some segment intersection routines and variables left over the code for a long time after IIRC.

[Micky C]

Quote

in the past, people have requested "sloped sprites". Assuming a sprite is only drawn once per frame in its entirety, what's the problem with that?

I can't think of any reason, but then I guess it would help to have in depth knowledge of rendering procedures, of which I have none