Weapon muzzles (and player noises?) occur from origin

[Paril]

If I fire from this position:

http://i.imgur.com/YreHJgt.jpg

I hear no muzzleflash because it's underwater.

[WickedShell]

Tacticool stealth shooting!

…

On Fri, Feb 10, 2017 at 11:56 AM, Paril ***@***.***> wrote: If I fire from this position: http://i.imgur.com/YreHJgt.jpg I hear no muzzleflash because it's underwater. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#408>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAipiAbm6wuidFOJK5dPlYGe0lUma7igks5rbLLggaJpZM4L9upD> .

[jdolan]

The muzzle flash takes places from the projected shot origin, so those are "correct" -- tho I agree that they are problematic with swimming in opaque volumes. That's one fix.

Entity sounds are indeed originated from the entity's origin. For client entities, we could modify this (with some hacks) in Cg_EntityEvent, to project the origin at least upwards, so it comes from the center of their head. I think we have Cg_IsDucking that can help.

[kaadmy]

Got an idea for this one, would it be possible to use md3 model tags for the sound origin if enabled?
Maybe have a new flag in s_play_sample_t to control it, S_PLAY_MODEL_TAG or something.
Could use the sound_source model tag by default, and fall back to head if it's not found, and if everything else fails, use the original method of using the entity origin.

[kaadmy]

Which sounds specifically should originate from the player's head? I'd guess all the drown/gurp/falling sounds.

[jdolan]

For clients, everything but the footstep and landing sounds should originate from origin + playerstate->view_offset. Footsteps should originate from origin + mins + vec3_up. The cgame module is probably the right place to handle this logic, so a Cg_ClientSample(cl_entity_t *ent, const char *sample, atten_t atten) or something makes sense. A quick strstr for "footstep" || "land" would branch the function, and then project the sample origin accordingly. Thoughts?

[jdolan]

The other change I think I want to make here, is to update quemap to not divide PHS by opaque liquids. Opaque liquids should be equally hearable with transparent ones. We'll have to re-VIS our maps that have opaque liquids (ugh, Gehenna..), but in this case, I think it's worth it.

[kaadmy]

Can you even get inside any liquids on Gehenna?

[Paril]

Don't strstr to figure out which path to use, use a flag on attenuation or something. Seems incredibly ugly to base it on the filename.

[jdolan]

Yea, attenuation is sent as a byte, and we only have like 4 attenuations, so we could use the high bits for these origin / offset flags.

[kaadmy]

Will try working on this one, how should the origin offset work for non-players?

[kaadmy]

Would the upper 4 bits as a signed int with an 8x multiplier for the Z offset from the origin be good enough?
Edit: I'm using a 4x multiplier

[kaadmy]

Also what maps have waist-deep opaque water to test this?

[Paril]

None, need to make some in sandbox.

[kaadmy]

Done, my fixes didn't seem to work
KaadmY cries

[Panjoo]

There's some waist deep water here in ThePits if you stand on the ramp.

(Btw I've asked Arseflute (Matt) to make a more useful sandbox map as he said he wanted to get refreshed on mapping in general. So I'm not sure if he'll also add waist deep water. JSYK.)

[kaadmy]

I made a new sandbox map yesterday already that has waist deep clear and opaque water ;)
I was also mainly asking about opaque water since that's what this issue is from.

[Panjoo]

Okay gotcha!

[jdolan]

@kaadmy can you provide an update on this ticket? Is there still work to be done here for sound origin placement?

@Panjoo in terms of gameplay impact, should we pursue changing our VIS algorithm to not separate PHS for opaque liquids?

[kaadmy]

I think in master I already implemented offsets but they weren't working properly for some reason, so I disabled them. Not sure though.

[jdolan]

This is still a problem. The following fixes should be made:

• Use Cm_BoxLeafnums to bitwise-OR PHS for all sounds. Entity sounds should use the full entity bounding box for PHS resolution.
• Per my comment above, opaque liquids should not serve as boundaries for PHS. This will be a quemap change, possibly to portal file authoring, and / or almost definitely to the VIS process itself.

[jdolan]

This is moot now, since we don't have PVS / PHS :)