OpenGL Sprite Clipping

[ReFracture]

One thing I've often wondered about Doom and the many source ports it has that utilize OpenGL rendering, why hasn't this been fixed yet?

GLBoom+


GZDoom


I've noticed that both of these engines utilize a 'sprite clipping' feature, with options such always, smart, and never. (Or constant in GLBoom+'s case), personally, with both engines, I leave it at always. I don't really understand the purpose of the other options, they seem to just make the enemies sink down into the floor further than they do in software mode...

[Spleen]

The software render always draws sprites over flats (floors/ceilings). So if you are standing on a ledge and there is a corpse down below, you will see it through the floor, even when it should be obscured by it.

On the other hand, the GL renderer draws things in a more standard way, drawing flats over sprites if needed. A side effect of this is that parts of some sprites are cut off. For example, a revenant is actually only as tall as the player, but its sprite is much higher. For this reason, its head gets cut off if there's a low ceiling in GL. However, in software mode, since sprites are always drawn over flats, its head does *not* get cut off.

Smart clipping is actually supposed to slightly shift the sprites up to avoid cutting off the *feet*, which probably sink into the ground, and thus get cut off in GL mode. It would be more complicated to avoid cutting the head off since you can't just shift the sprite (since this would just cause a lot more of the feet to be cut off), and the head gets cut off in less situations anyways.

[ReFracture]

I tend to wonder if there is a way to tell the GL renderer to prioritize the sprites of monsters over that of flats... I can completely understand putting flats before sprites (though in all honesty I have completely forgotten that sprites can poke through flats, it's been a long time since i've seen that.)

[Graf Zahl]

It's not that easy. Ordering in a hardware renderer is done by a depth buffer. And the depth of the sprites' pixels is higher than the floor so they get clipped. Disabling the depth buffer is not an option because it's the only reliable method to do proper ordering of all elements.

Hardware rendering offers some kind of prioritizing in form of a stencil buffer but that's in general unsuitable for drawing sprites in a scene because it'd had to be set for each sprite separately and that's not possible, unfortunately.

[Siggi]

It really is unfortunate, because this is one of the issues which prevent me from using Doom ports that use OpenGL.

It's just something I can't ever get used to.

[Graf Zahl]

Actually I'm on the opposite side by now. I find the sprite bleeding into the floor just weird.

[Enjay]

Graf Zahl said:

Actually I'm on the opposite side by now. I find the sprite bleeding into the floor just weird.

As do I. I really noticed it when I was testing a map in a few different ports recently.



I don't think this point has been answered fully: the apparent making the enemies "sink down further than they do in software" probably isn't the case. Most sprites in Doom that are intended to sit on the floor have a Y offset of about 4 units less than their height. What this means is that the bottom of the sprite is actually 4 units lower than the floor but drawn over it in software mode. In certain situations this can be very obvious. eg freeze the game on map02 (eg using Zdoom and the freeze console command) and move around on the lower level in front of the ledge where the zombies stand near the player 1 start. Look at the sprites on the ledge and you should see the effect quite clearly there.

In OpenGL, because of the technical issues that have been explained, the bottom of sprites which extend into the floor get cut off. So, smart or always will move some or all of the sprites (respectively) up so that their bottom edges are no longer cut off by the floor. Switching between the shifted-up and unshifted settings may, coupled with the enemy's lack of feet, make it look shorter when it drops down to the lower height but it shouldn't be any lower than in software.

One thing I do find with the OpenGL solution, however, is that because the Doomguy has such a low view height anyway (41 units - putting his eyes somewhere in his chest) raising the enemies makes the Doomguy seem even shorter when he is right up close to the bad guys. In my own mods, I like to use a custom player class with a more realistic view height. That's also better for crosshair aiming.

[40oz]

Is there a way to "scale" the monsters sprite down in the event that it's in a room where it's sprite would be clipped? It may look weird to see a revenant look shorter in a small room than he does when he comes outside, but it would certainly look better than being temporarily decapitated.

[DaniJ]

Q: Why hasn't this been fixed?

As Graf already pointed out; if it were easy, I'm sure at least one of the current GL ports would have implemented it by now.

However, I do think I know of a possible solution yet it would absolutely result in a guestimated 30% performance loss and would likely result in other render artefacts. Clue: most modern 3D game renderers do it already if DirectX 10 is available.

As for scaling the sprites to fit within the height range of the current sector: this could be done very easily but I personally think that it would look even worse.

[Enjay]

And, ultimately, the monsters losing their heads is the fall out of sloppy work by id IMO. Why, for example, make an actor 56 units tall when its sprite is up to 92 pixels tall (revenant)? Silly id. ;)

[hawkwind]

Yes, it is clearly obvious that Plutonia 2 was only tested in software. I noticed that in one level there were plenty of revenants with their heads in the ceiling. Since most people - I think - use Doombuilder, ( or any other editors config file for that matter ) they could open up the config files and change the height of the revenant for example and change it from 56 to 92. This would be a reminder to map authors of the revenants maximum height.

Or just that map authors also check their wad in an ogl port.

[GreyGhost]

One stop-gap solution would be a DeHackEd patch to set the revenant's - and a few other monsters - height closer to it's pixel height.

[Graf Zahl]

... and break half the levels that use this monster.

[ReFracture]

GreyGhost said:

One stop-gap solution would be a DeHackEd patch to set the revenant's - and a few other monsters - height closer to it's pixel height.

Unless the wad was completely designed around that... that is just not an option.

Well thanks for the responses on that. It was pretty puzzling. I can't say I fully understand it all (having no programming experience and knowing next to nothing about hardware renderering), but it's good to know it isn't just people being lazy.

[GreyGhost]

Graf Zahl said:

... and break half the levels that use this monster.

I for one wouldn't mind having fewer revenants roaming around trying to pack-rape me. ;-)

[Gez]

Enjay said:

And, ultimately, the monsters losing their heads is the fall out of sloppy work by id IMO. Why, for example, make an actor 56 units tall when its sprite is up to 92 pixels tall (revenant)? Silly id. ;)

My pet theory is that they intended the revenant to be 56-tall, but kept its sprites 92-tall because they had no other way to keep it detailed enough. (People are already thinking the blood on its basin and leg bones is hot pants, it would be even worse if the sprites were shrinked a 56-height; and Doom had no sprite scaling system.)

[Vermil]

Actually, most of the non-boss bad guys in Doom are 56 high.

The Mancubus, Arachnotron and Barron/Hell Knight are the exceptions all being 64 high.

Keen is 72 units high.

[entryway]

rend-sprite-noz or r_nospritez in earlier Rised3d

[Csonicgo]

entryway said:

rend-sprite-noz or r_nospritez in earlier Rised3d

if you can add something like that in prboom+ it'd be quite cool.

[DaniJ]

Well yes but there are obvious side-effects and inherent disadvantages to disabling depth buffer writes when drawing sprites.

[myk]

Enjay said:
Most sprites in Doom that are intended to sit on the floor have a Y offset of about 4 units less than their height. What this means is that the bottom of the sprite is actually 4 units lower than the floor but drawn over it in software mode. In certain situations this can be very obvious. eg freeze the game on map02 (eg using Zdoom and the freeze console command) and move around on the lower level in front of the ledge where the zombies stand near the player 1 start. Look at the sprites on the ledge and you should see the effect quite clearly there.

It's to manage an impression of depth, as that is used mainly on feet that are closer to the viewer than the rest of the body, giving the sprite the overall impression of being centered on the level of the floor. It can look a bit odd on a ledge if looked at from about the height of the ledge surface. Incidentally, the Map02 ledge where the three zombiemen stand is 40 units off the floor from where the player can stand.

Gez said:
My pet theory is that they intended the revenant to be 56-tall, but kept its sprites 92-tall because they had no other way to keep it detailed enough.

Various DOOM II monsters seem to have the discrepancies while the ones for DOOM seem more accurate. This could be because they didn't care at that point (didn't find that exact heights generally seemed noticeable), because they forgot to give each monster a unique height when they wrapped things up, or they just didn't coordinate between programmers and artists on that. The latter possibilities could have happened if some guys (maybe the artists) finished up near the release schedule.

Adrian: "Hey guys, make sure the arch-vile is 64 units tall"
John R.: "Yeah, wait, let me finish The Living End here!"
John C.: "Mhmm..." *thinks about way to optimize Quake engine*

Also, what Graf Zahl said, but during development itself. If revenants had been placed in the WIP levels early on before their sprites were done, changing the height to a higher value would possibly have made some get stuck. You can't force the artists to draw a new monster and there's no time to edit all those levels, hence the heights remain unequal.