Culling the glitches away

Truecolor ZDoom with extra features and some unofficial/beta GZDoom features.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Libs (Win)] [Repo] [Bugs&Suggestions]

Moderators: Rachael, dpJudas

User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Culling the glitches away

Post by Rachael »

Haha, pun, get it?

Okay, onto more serious topics...

I've been thinking a lot about the culling algorithms, and also noticed how when you disable them the old problem returns where triangles stop drawing if any part of them appears offscreen.

Which got me wondering ... is it possible to render the entire scene without culling? Framerate be damned - I just wonder if it's possible to try for a "glitch-free" render, first, and then maybe it might be possible to tweak the culling algorithms a little more conservatively so that entire subsectors stop disappearing?

I played around with r_poly_cull.cpp a bit, but had no success. When I did manage to disable things, all it did was introduce the offscreen triangle problem again.

What I have noticed is that when one vertex of a subsector is behind a player's Z point (post-transformation view, regardless of pitch) the entire subsector gets culled away. This almost seems to happen randomly but there's a hallway near the beginning of E2M6 where I can reliably make this happen. It's the eastern-most hallway leaving the entry room, the one that has the marine body in it.

About the triangles disappearing - maybe it might be possible to put range checks on the drawers directly so that only part of them gets drawn?

On a somewhat unrelated note, I think I am ready to tweak the sprite render modes if the drawers are already accepting mode inputs that I can easily add - since you said it would be easier if you added at least the mode parameter, if I recall correctly.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

There are several stages of clipping and culling going on. One or more of them might be buggy at the same time. Just for clarity of discussion I'll list them:

1. BSP node axis-aligned bounding test. This is the first thing CheckBBox does.
2. Solid segment BSP node visibility test (also in CheckBBox). If #1 passes, then it checks if the BSP node's bounding box has been blocked by a wall.

The purpose of those two tests are to skip entire subtrees of the BSP tree. After this pass completed it collected the list of visible subsectors in PvsSectors (the scene's potential visible set).

Now it begins to render each subsector in a front to back manner. Here it uses two culling tests:

3. First a front-facing line culling test ("Reject lines not facing viewer") to skip walls.
4. Then another solid segments test to see if the wall is at all visible. Note that while this test uses the same functions as in #2, it reset the list of solid segments and thus is completely independent of the original testing. This is to try improve fillrate performance (overdraw is the primary loss of speed atm).

The translucent objects got no direct culling (they all get rendered), but they use a "subsector depth" as a kind of zbuffer test for each pixel. I am deliberately not doing a Z test because I am trying to avoid having the floor/ceiling sprite clipping problems that GZDoom has. The approach I'm using for calculating this depth is a little bit too naive right now.

When something passes all those culling tests above it generates vertices and draws some triangles. Each triangle is then subject to three things: A) frustum plane clipping (znear, zfar, and 4 other planes), B) front face culling test, C) per-pixel stencil test or subsector depth test.

Anyway, since I don't know yet exactly which of all those tests fail right now, I'm not sure which you're trying to repair. However, tests 1, 2, 3 and 4 can all be disabled without it changing the visuals of the scene. First two are done by making PolyCull::CheckBBox return true, and last two by remarking the return statements in RenderPolyScene::RenderLine.

If you figure out which of the tests are failing I'm all ears. :) I've noticed it happens when you stand at some exact spots, and then also when looking up into the ceiling.

About sprite render modes, I'm planning on adding the blend modes to the drawers this weekend. When that's done you should be able to tweak sprites/walls/planes/decals to use any of the render modes the original renderer had.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Alright. I'll take a look at the culling stuff later. I know pixel fill rate will kill any software renderer but I do have a fast CPU and I do want to try and see what's causing it to fail. I've also lived with crap computers long enough to be able to make jokes when the frame rate gets lower than 1. ;)

@ Render modes: Fair enough.

With tweaking the drawers, what about adding a multiplicative filter color, too? This would make it easier to add in colored sectors (something that I am very well known to advocate when people are complaining about OpenGL "destroying" their purdy drrk roomz). You don't have to, though, I could try to do it myself. XD I haven't ever tried touching LLVM-targeted code yet, though.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

The frame rate won't get as bad as 1, because luckily things far away also get very small. :)

Adding new blend modes is fairly easy - but you need some way to select them in the zdoom part of the codebase. Exactly what that takes I don't know - I'm still not entirely sure how it picks the render style as the code deciding it is just beyond my reading capabilities. I'd have to study it, slowly, line by line. Probably easier to figure it out by becomming a modder first than use the code. :D
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

It's fairly simple. Midtextures can either be translucent or additive, provided the "2-sided linedef" flag is set. Sprites (things) can be any one of these: https://zdoom.org/wiki/Actor_properties#RenderStyle

The relevant properties are set from the same section. Other than that, there's not much to it.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

When you put it like that it sounds simple enough, but when you see it from the code side in the software renderer it seems far more complicated. R_SetPatchStyle, R_SetBlendFunc and the functions juggling render styles before calling any of those.

On the plus side, it sounds like you're just the kind of girl needed to set this up in the poly renderer. :)
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

I'll do it. Just let me know when you're ready with the drawer inputs and stuff. :) Unless you'd rather I do that? I'll make a test mod to try out all the different render styles so that I can compare them across renderers.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

I'll do the drawers and then you'll hook them up. That sounds great to me!
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Alright. I'm going to make the map now, then.

And done.
pinkys.pk3
(4.96 KiB) Downloaded 234 times
Screenshot_Doom_20161118_143542.png
Screenshot_Doom_20161118_143542.png (311.08 KiB) Viewed 5120 times
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Blue pinky is back!
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

Could never go a full testing phase without him. :)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Okay, I've added support for all the blend modes the old renderer had. We should be ready to render all the pinkies now, except fuzzy pinky.

Note that the boot time has gotten a lot worse from this because it now needs to generate code for about 60 new drawers (4 draw variants, 8 blend modes, 8 bit and 32 bit). I'll work a bit on caching the codegen output, but at least all the render styles should be possible now.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: Culling the glitches away

Post by Rachael »

So did you already hook them up yourself? XD I was going to do that, but it's okay if you did. The way I was going to do it probably would've been a little simpler, but whatever works. :) I guess your way would have resulted in higher framerates anyway since you're using unique functions for each drawer.

EDIT: Nevermind, I see the work cut out for me. :)
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

Yes, only did the drawers themselves. :)

You switch between them by specifying a different TriBlendMode to PolyTriangleDrawer::draw, and then you need to make sure the uniform arguments used by that drawer are correct. For example, for a translated add, you need to set args.translation to point at a translation and also set the uniform srcalpha and destalpha values to something meaningful.

Feel free to change the contents of RenderPolySprite::Render as much as you'd like. It is currently made out of mostly fragments from the old renderer to try get reasonably close to what the old one did and ideally at some point this would be cleaned up a bit.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Culling the glitches away

Post by dpJudas »

I've pushed an update that caches the optimized bitcode. This adds LLVMBitWriter.lib to the dependencies, which is currently only available in the llvm-3.9.0-everything.7z I created.

It still takes it a little while to boot, because just doing the bitcode to machine code takes a little while. I'll fix that at some point by precompiling everything into an .asm file, but that's sufficiently boring for me not to bother right now.
Locked

Return to “QZDoom”