| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003816 | The Dark Mod | Textures | public | 16.08.2014 17:30 | 12.09.2014 18:54 |
| Reporter | Springheel | Assigned To | Springheel | ||
| Priority | normal | Severity | normal | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | TDM 2.02 | ||||
| Fixed in Version | TDM 2.03 | ||||
| Summary | 0003816: citywatch tunic doesn't spawn wound decals | ||||
| Description | Not sure why this is...when skins swap it for the cloth version, it doesn't register blood decals, even though the arms and legs, which use the very same texture, do. When the texture is set to plate, arrows bounce off properly. | ||||
| Tags | No tags attached. | ||||
 |
Exactly when and where should blood decals appear? In my tests on city watch I've been shooting at head and hands because I've only seem wound decals on exposed flesh, at least from non lethal wounds. If you tell me how to rep the circumstance you're looking at I'll have a look. The decision whether to spawn a decal is made in the bit of code I'm messing with for the persistent decal issues. |
 |
When you fire an arrow at a surface that is marked as "flesh" or "cloth", it should spawn a wound decal on the body. By default, the citywatch arms/legs are set to "cloth", and the torso is set to "chain" (which doesn't spawn wounds). However, on citywatch using the cloth skins (where the chainmail is swapped for rough cloth), the torso then uses the same material as the arms/legs, so it should now register as "cloth" and behave accordingly. However, I cannot get wound decals to appear in that case. At first I thought it might be because the new surface type was not being applied properly, so it still registered as chainmail, but tests with platemail surfaces behaved properly. To reproduce this, take a citywatch and give him any of the skins that has cloth sleeves instead of chain ones. Then KO him and shoot the torso. No blood appears. (I have to test this further to be sure, but I don't think I was getting wounds on the townsfolk_female's torso either.) |
|
|
The skin switch is working. When you shoot chainmail, the blood splat code tries to look up "mtr_wound_armor_chain" in the damage def, doesn't find it, so no wound is applied. With the cloth skin, it successfully looks up "mtr_wound_cloth", maps it to textures/decals/hurt_small (via the damage def in tdm_weapon_arrow.def), and applies it. The blood is hitting the cloth underneath the halbard though, not splashing the halbard itself. You can see it if you noclip inside the wounded guard. I wondered whether the halbard was non-solid, making the point of impact the cloth underneath, so I tried hacking the code to move the origin of the bloodsplat back by one doom unit, so it'd be outside of both layers. That didn't help: the blood splat still ignores the halbard. I'll try to work out which layer in the mesh is the halbard so I can see why the renderer skips it when it applies the decal. |
|
|
It's the 4th layer. The game code correctly picks up the new skin as the collision material, but when the renderer comes to apply the decal, it checks the surface material in the model def to see whether it can support overlays. It picks up the "citywatch_chain" material definition. And it doesn't try to apply blood because citywatch_chain is a transparent (alpha tested) material -- those apparently don't support any overlays ever. Edit: sentence removed about "original model def" because that might be wrong interpretation. I'll update this post later as we're all going out for lunch. |
|
|
What do you mean by "halbard"? That's a type of weapon. "citywatch_chain is a transparent (alpha tested) material -- those apparently don't support any overlays ever." Ah, that explains it. That would also explain the townsfolk female, since that texture has small transparent areas too. |
|
|
I meant "tabard" not "halbard". Oops. I confirmed that the Overlay logic is ignoring skins. Reskinning the tabard to cloth isn't helping because when the renderer checks the material, it's checking the original model def and ignoring the skin. So it still thinks the tabard is "citywatch_chain". It looks fixable. Every other place I've seen in the renderer that deals with a shader on a model first passes it through a routine called R_RemapShaderBySkin, which applies the skin changes before further processing. The code in ModelOverlay.cpp doesn't do that. It doesn't even know about the skin right now, because only the base model is given to it to work on. I couldn't decide earlier whether this was a code fix or a def fix. I think now it's a code fix. It would be hard to fix it in the def files without making the tabard bleed when there's chainmail under it. I'll run a test to see whether it works as expected. |
|
|
Now I'm confused, is it a skin issue or an alpha issue? I can imagine good reasons to not put overlays on alpha textures, even though in these specific cases it would be fine. |
|
|
That works! All 3 things are involved -- code, alpha, and skin -- but the code is what wanted fixing. For once, it's a simple fix and it makes the code *more* consistent, so no difficult design decisions to be made. The way it's set up: if an actor gets hit, he or she has a spawnarg to say they can bleed, so there's a check on what type of material got hit to see whether it should allow bleeding. Tabards are made of cloth which would normally allow bleeding, but when they're over chainmail we don't want them to bleed. So they are given armor_chain instead of cloth as a material type by default. That blocks the blood overlay from being generated in the first place, because there's no blood decal defined for armor_chain. The cloth_hauberk skin remaps the tabard material to its natural cloth, so that it won't block bleeding any more. But you still don't get blood, for 2 reasons: 1) The renderer code ignores the reskinning 2) The renderer doesn't apply overlays to alpha materials. The tabard doesn't really seem to have any transparency in it, but the renderer thinks it has because the "citywatch_chain' material used as the fake "chain" tabard texture has an "alphatest 0.5" in it. The alternative skin material is citywatch_cloth -- which looks the same but doesn't have the alphatest. I wonder if the dummy alphatest line in the material def was an earlier attempt to stop chainmail bleeding? I suspect that removing that line would have fixed this issue equally well. But whether or not that's true, I reckon it's right to fix the overlay code so that it makes the correct decisions on skinned models, and that's enough to fix the issue. |
|
|
No, the alpha is there because the texture has a very small transparent part to it (a ring in the part of the belt that holds the sword). Ah, actually you've found a flaw in my textures...those cloth materials SHOULD have an alpha stage, just like the chain--currently the ring doesn't look right. So if I fix that, we're back to no blood decals, I take it? |
|
|
Unfortunately that's right :( Can that ring be separated somehow? Or perhaps sacrifice the hole in the ring for the blood? I'll try to attach a pic like I saw grayman do with his small spider. I'll still apply the fix I've tested. It'll cure future bugs with overlays on skinned meshes. |
|
|
I guess ideally the transparent part could be separated onto a separate layer in the md5mesh, with its own material. But redoing the mesh, and the LOD meshes, and redoing all the skins, is not a can of worms I'm eager to open right now. :( There are also certain textures, like the tunic with the ragged edge, where the transparency is part of the torso, that can't be fixed in this fashion. I'll make a new tracker entry. I expect this affects a number of AI, we just haven't noticed because most of them wear chainmail by default. |
|
|
Reluctantly I agree, the majority case wins. Most guards are wearing chainmail and wouldn't benefit from the fix anyway. Your time is better spent on new models and lod models (the new ai are going to knock peoples socks off in 2.03!) When I get home tomorrow I'll raise a tracker too and commit my fix. It'll make bleeding more predictable and controllable. |
