Decals being projected through walls

I have this problem with decals, placed by a thing, on one side of a sector also appearing on some lines on the other side.

What's the cause of this and what can I do?

http://imgur.com/GnMc8xX

Are linedefs flipped same?

NinjaLiquidator said:

Are linedefs flipped same?

Yes, and flipping them makes no difference.

Try placing the decal thing further away from the wall.

scifista42 said:

Try placing the decal thing further away from the wall.

Tried that, it only changes on which lines it shows up on on the other side. The only thing that has sort of helped was making the wall thicker.
Maybe the size and offset might have something to do with it?

Post the map, not a screeshot if you want some help. Nobody can analyze or debug an image.

Graf Zahl said:

Post the map, not a screeshot if you want some help. Nobody can analyze or debug an image.

I never thought anyone wanted to. But if you want to I'm not going to say no.

https://www.dropbox.com/s/s8xl38en3l9xlrx/ep1test.wad?dl=0

First map on the outside at the start.

Missiles can sometimes pass thru the obvious impact surface, before being detected as colliding with the other side. This is because a fast missle may be a single unit or two away from impact at, say, tic 100, but at tic 101, that missile will have moved a large distance (based on it's speed), which could place it well within the wall. Only then is the missile checked for collision, and as soon as Doom decides that the missile could have collided with a wall, any wall, it stops checking. It could choose the expected wall, or it could choose the wall behind the obvious point-of-impact, if the missile has traveled within the wall.

This is precise enough for an explosion, but not precise enough to always place the decal properly.

The effect of the wrong wall being chosen can be reduced by:

. Slower missiles
. Thicker walls

But, realistically, it's going to get it wrong sometimes.

kb1 said:

The effect of the wrong wall being chosen can be reduced by:

. Slower missiles
. Thicker walls

But, realistically, it's going to get it wrong sometimes.

What are you saying here, that the ZDoom decal thing "shoots" out the decal like a missile and does it so fast that it can clip through walls?

The thicker walls I already know about though.

I suspect that kb1 only read the thread title, but not your posts carefully enough, and didn't acknowledge that you're talking about pre-placed Decal actors, as opposed to normal projectile's impact during the game.

I looked into ZDoom's source code (a_decals.cpp). The Decal actor actually fires a hitscan trace behind itself, with maximum distance 64. If the hitscan trace hits a linedef, the respective decal will be applied onto a respective part of the linedef. Then, if a CVAR "cl_spreaddecals" is set to true, it will automatically call a "smart" function called "Spread" to distribute the decal graphic onto nearby linedefs in case it didn't fit onto the one linedef found by the hitscan trace. This "Spread" function apparently doesn't work perfectly, your terrain of multiple interconnected double-sided linedefs confuses it, and so it applies decals to places where they logically shouldn't be (the worse that your decal is large). When I set "cl_spreaddecals" to false, the decals didn't project to the back wall, but they didn't cover the entire front wall, instead they displayed only on 1 linedef per Decal actor, as expected.

Thanks for taking time to test this. The reason to use decals was to save time and not have to do a new texture for every instance where I want to do some blending.

If this is just a problem with those kinds of walls, then maybe I could do those places manually... Will have to see I guess.

scifista42 said:

I suspect that kb1 only read the thread title, but not your posts carefully enough, and didn't acknowledge that you're talking about pre-placed Decal actors, as opposed to normal projectile's impact during the game.

Well, you're half-right: I read the rest, but was not aware that decals could be placed on level load. I assumed that a decal was the result of something being shot at a wall during gameplay.

However, reading the rest of your text (that I didn't quote, it sounds like ZDoom is doing just that (shooting the wall) to support this Decal Actor, anyway. So, my original thoughts still apply, with one difference: Hitscan decal code will necessarily be different than missile decal code, because hitscans use line intercepts, whereas missiles have a bounding box (as does this Decal actor, I suspect).

Line intercepts are not susceptible to the "missile exploding inside the wall" issue. However, vanilla line intercept code did have some fail-to-intercept cases. ZDoom fixed this issue, at least for hitscan-to-monster collision testing, but I'm not sure about decal-locating hitscan code. (It's probably ok as well).

At any rate, giggling wall thickness, and moving the Decal actor back a bit (but not too far) might do the trick.

Good luck!

kb1 said:

vanilla line intercept code did have some fail-to-intercept cases. ZDoom fixed this issue, at least for hitscan-to-monster collision testing, but I'm not sure about decal-locating hitscan code. (It's probably ok as well).

At any rate, giggling wall thickness, and moving the Decal actor back a bit (but not too far) might do the trick.

No, it won't. The hitscan code works correctly, and indeed finds the correct place on the correct wall. The problem is that the decal is large, and the decal-setting function will try to "wrap it" around linedefs neighboring with the affected linedef, expecting that the linedefs are forming a continual surface. However, Knas's structure consists of multiple rectangular sectors with linedefs touching each other. That's why the decal-setting function wraps the decal onto incorrect walls.

Can the decal be split up, with multiple decal actors? More than one way to skin a cat...

Or just use a feature that Doom has had for years; Texture patches. It's even vastly more efficient for the renderer, too. SLADE3 makes these easy to construct with visual editors for both TEXTUREx and ZDoom's TEXTURES.

Edward850 said:

Or just use a feature that Doom has had for years; Texture patches. It's even vastly more efficient for the renderer, too. SLADE3 makes these easy to construct with visual editors for both TEXTUREx and ZDoom's TEXTURES.

An excellent point.