Jump to content
The Dark Mod Forums
Sign in to follow this  
Fidcal

Collision Sound Alerts

Recommended Posts

Okay, assuming no air friction:

2*a*Dx = v^2 - v_0^2, with zero initial velocity gives:

v = sqrt(2*a*Dx)	  [1]

Or, solving for Dx with a known velocity:

Dx = v^2 / (2*a)	 [2]

 

Now, if we use the real acceleration due to gravity of a = 9.8 m/s^2 and convert to inches/s^2 we would get a = 385.83 in/s^2. If we say a doom unit roughly equals an inch and solve for the Dx required for the clamped value of 200, we would get:

Dx( v = 200 du/s, a = 386 du/s^2 ) = 52 inches or 4.3 ft.

That's the height where the volume clamps, and that seems somewhat reasonable (would be nice if it were a little higher).

 

But Doom3 seems to use 1066 units/s^2 (why I don't know, might have to do with how the air drag coefficient for moveables is set to 0.6 by default, which seems really high). Using that gives:

Dx( v = 200 du/s, a = 1066 du/s^2) = 19 inches or 1.6 ft

Now that doesn't take the high air drag into account, so the real answer is probably a bit higher than that.

 

Testing ingame with angua's new cvar (tdm_show_moveable_collision), and dropping the wooden bowl on carpet, the max velocity of 200 is reached closer to 1.5 ft than 4.3 ft, so it seems it really is using this crazy value of 1066 for gravity. It's a bit hard to tell how high you're dropping something from (would probably need a ruler along a wall or something for an accurate test), but it seems like it can reach v_max = 200 when dropped from much less than 4 ft, somewhere around 2 ft. So there's no real difference between dropping things crouched and dropping things standing.

 

Conclusions:

We probably don't want to change gravity at this point. It may or may not work if we increased gravity and set the high default air friction on every entity to a realistic small value (our moveables are all still using the D3 default of 60% drag). Anyway, assuming we don't want to change gravity, we could increase this max volume velocity to make more of a difference between 2 ft drops and 6 ft drops.

 

Using [1] with a = 1066 and Dx = 6 ft/72 inches, we get a velocity of 391. So setting the max velocity to 400 might be reasonable? That seems okay ingame, that corresponds to dropping it while standing and looking up somewhat (at the min. hold distance for the wooden bowl), looks like about 6 ft.

 

Maybe we can keep the same 20 dB volume range over that larger distance (min-6ft instead of min-2ft which it is now)? That would mean volume goes up a little more slowly with velocity compared to what we have now, but that's probably okay, right? Alternatively we could increase the range to 25 dB or something, but that might require tweaks to increase the minimum volume if we're happy with what that is now.

Share this post


Link to post
Share on other sites

@Fidcal:

I think you already know this, but just to clarify, the volume in the sound shader is the maximum volume that will ever play. So it should be set with dropping it from the maximum height in mind. Everything is probably fine, since the sound shader volumes seem okay to me, but right now the max height may be too low at about 2 ft.

 

@Dave:

I didn't notice much difference in the sound played between scraping something sideways and setting it down vertically. There's a Grabber bug that plays high-velocity collision sounds in both cases, when you slide the object too far along the plane it's colliding with.

 

It's probably more difficult to control/tell if you're hitting things sideways. The pitch rotation of the object is also maintained when you tilt up and down, so if you had oriented it to lay down flat, it will stay flat. But the yaw is not maintained when you go side to side, so it's probably harder to set it with the flat surface against the side-wall. Maybe that's also making the error worse when it tries to rotate against the wall in addition to slide, but I didn't notice a big difference.

 

 

[EDIT: We should also test throwing objects as a distraction and make sure that still works to our satisfaction]

Share this post


Link to post
Share on other sites
@Fidcal:

I think you already know this, but just to clarify, the volume in the sound shader is the maximum volume that will ever play. So it should be set with dropping it from the maximum height in mind.

In this excercise I'm not dealing with sound shaders at all but only alert levels. I'm using positive and negative offsets from a default "vol" but I presume this is just a value that the code uses to propagate what I would call a 'signal' to AI.

Share this post


Link to post
Share on other sites

@Ishtvan: I see now, I think: I was only specifically speaking about setting something down silently, versus touching the wall silently (which I was saying doesn't ever seem to work), but the reality is that touching the wall always contains some small scrape component to the motion, and that is what's making the sound in question.

Share this post


Link to post
Share on other sites

The velocities are now cvars, "tdm_bounce_sound_max_vel" and "tdm_bounce_sound_min_vel". I also increased the default maximum velocity to 400.

Share this post


Link to post
Share on other sites

Okay, I tested ingame and a max of 400 seems more reasonable for the audible sounds. The volume varies over the full range of 0-6 ft or so. The max drop distance at which it clamps is a tad higher than eye height for the standing player, but I think it's a good maximum in case something falls off of a slightly higher shelf, or the player intentionally throws it in the air or something. @Angua: Do you agree?

 

@Fidcal: Ah, I misunderstood and thought you were also tweaking the volume of the audible sound shaders used for collision sounds. When the time comes to do that, we just need to keep track of the max velocity setting. Right now at 400, it corresponds to the bottom surface being ~6 ft/2 m off the ground and falling straight down.

 

Testing ingame with the max velocity of 400, the AI volumes may need to be slightly louder now. In other words, the AI sensitivity effectively went down because before we were treating anything dropped from 2 ft or over as if it was dropped from 6 ft, now a drop of 3 ft really is a drop of 3 ft and the AI are less sensitive to it than in the previous round of tweaking. If you knock a wooden bowl off of a 3 ft high table, it probably should still alert the AI across the room.

Share this post


Link to post
Share on other sites

@Fidcal: Are the AI volumes okay with you now that they represent stuff dropped from the intended max height and are now softer dropping from 2 ft and 4 ft? IMO the AI sound volumes could go a little louder now, but I wanted to check with you to avoid stepping on your toes by tweaking things myself.

Share this post


Link to post
Share on other sites

Not had time for this for a few days and probably not for a few more days.

 

What exactly did you plan on tweaking? The values on the individual entities in the test map or the vol in entityDef sprGS_bounce_default or something in the code? Or something else?

Share this post


Link to post
Share on other sites

I think the AI volumes and alerts are about right now, but the audible volumes could use some tweaking. I almost wasn't able to hear dropping the crate on the carpet, while the AI still heard it well enough...

Share this post


Link to post
Share on other sites
What exactly did you plan on tweaking? The values on the individual entities in the test map or the vol in entityDef sprGS_bounce_default or something in the code? Or something else?

The sprGS_bounce_default. For intermediate distances, it probably went down compared to when you were testing. It won't achieve that volume you were testing at unless dropped from about 6 ft now. Angua is saying it's still good though. I'll do some more testing tonight.

Share this post


Link to post
Share on other sites

OK, sprGS_bounce_default was originally about 40 I think. I tried some higher values previously then put it back down to 45 where it is now. I don't know what other repercussions there might be from changing that. If angua thinks that is about right then I suggest leave it where it is as the basic default.

 

Now, there will be offset definitions. I may have already put placeholder names in but that is irrelevant at the moment. We are only concerned with the test values on each entity in the test map.

 

Feel free to change the values in the test map. There is one of each basic type. You can do that in a text editor if you prefer. Just search down in propagation3.map for sprS_bounce and sprS_bounce_carpet. That is all that is being used at the moment to determine what values we will eventually put in the default offsets.

 

Once they are agreed then we can go to the next stage and apply those to every entity. Later, the offset defaults or the main default can be fine-tuned slightly if necessary.

Share this post


Link to post
Share on other sites

Well, I didn't test it thoroughly, I only spent a few minutes throwing the stuff around in the map...

Share this post


Link to post
Share on other sites

Oh, I thought there was some techy reason, eg, something peaks at a certain level or something. :) Well then it might be easier to raise that to 50 or something instead of each of the 8 test objects.

 

Sorry I'm a bit out of this because I am so busy with so many things. :laugh: But I will get back to it.

Share this post


Link to post
Share on other sites

I went and tested in propagation3 again, and the AI version of the sounds seem a bit soft to me. I think it was perfect the way you initially set it up Fidcal, but then we went and changed the physics on you, so the baseline volume might have to be a bit louder.

Share this post


Link to post
Share on other sites

OK thanks. I am finishing off Startpack 2 over the next few days then I plan to get back to this as my next task.

Share this post


Link to post
Share on other sites

Reviewed this and some of the sounds might be slightly low but that might be what people want so I'll use these for now.

 

Plenty of time has passed and there have been no objections to the groupings so I'll go ahead now and set up these groups on all entities. (if anyone objects later they can change them all themselves. :laugh: )

 

Once that is done then any tweaking of alert values need only be done on the defaults.

Share this post


Link to post
Share on other sites

These are the groups I'm setting up (not committed yet.) The actual values are not critical yet as we can easily adjust these 9 defaults:

 

"sprS_bounce_min_soft_on_hard" "bounce_default:-10" // quill, sheet paper, scroll on stone, tile, wood, etc.

"sprS_bounce_min_hard_on_hard" "bounce_default:-5" // ring, coin, key, small book on stone, tile, wood, etc.

 

"sprS_bounce_mid_soft_on_hard" "bounce_default:-8" // apple, loaf, small bag on stone, tile, wood, etc.

"sprS_bounce_mid_hard_on_hard" "bounce_default" // goblet, trophy, big book, on stone, tile, wood, etc.

 

"sprS_bounce_max_soft_on_hard" "bounce_default:" // sack, package, boars head, on stone, tile, wood, etc.

"sprS_bounce_max_hard_on_hard" "bounce_default:10" // crate, chair, cauldron, barrel, on stone, tile, wood, etc.

 

"sprS_bounce_min_on_soft" "bounce_default:-11" // quill, paper, ring, small book, on carpet, snow, grass, etc.

"sprS_bounce_mid_on_soft" "bounce_default:-10.5" // loaf, goblet, trophy, big book, on carpet, snow, grass, etc.

"sprS_bounce_max_on_soft" "bounce_default:-6" // package, crate, cauldron, barrel, on carpet, snow, grass, etc.

Share this post


Link to post
Share on other sites
Reviewed this and some of the sounds might be slightly low but that might be what people want so I'll use these for now.

 

Don't mean to be combattive, but why is this what people want? Personally I thought it was perfect when you set it before before, but the problem was it was clamping out at a 2 ft drop, so it didn't actually get louder beyond that. Now you can probably set the max AI volume louder because it corresponds to a 6 ft drop, not a 2 ft drop like before.

 

Personally I tried it and thought it was too soft. They used to hear the pot dropping from your starting position in propagation3, right? Now you probably have to drop it all the way from 6 ft for them to hear it, when it seems like they should hear it from over there when it just falls off a table (~4 ft?)

Share this post


Link to post
Share on other sites

That's OK. The actual levels are still up for discussion. I'm focusing right now on defining and assigning the groups then levels can be tested in any mission and any situation as well as the test map. Meanwhile I'll re-assess and raise some of the levels a bit.

Share this post


Link to post
Share on other sites

Have now raised most of the sounds levels for further testing. The velocity of impact allowance is very noticeable now and you can carefully place a hard bowl on stone behind the AI without alert. But drop it from higher and he alerts. Only the larger items have much affect on soft surfaces like carpet and even then only if very close.

 

I just realized my new group names will have no effect unless they are recognized in the code. Can someone confirm that or do I need to do something different in the defs? For example, how does the code know that the existing "sprS_bounce_carpet" is only effective on carpet? So if I use "sprS_bounce_min_on_soft" how will it know that is any soft surface?

Share this post


Link to post
Share on other sites
For example, how does the code know that the existing "sprS_bounce_carpet" is only effective on carpet? So if I use "sprS_bounce_min_on_soft" how will it know that is any soft surface?

The code is appending the material name (carpet, stone, tile, etc.) to check for the spawnarg. "on_soft" is not a material name, hence it won't be recognised.

Share this post


Link to post
Share on other sites

So how do we do it? We have 6 on hard and 3 on soft. If a separate one is needed for every hard surface and every soft surface it might be 100 plus definitions. Presumably we need two generic names to be recognized by the code, eg, 'hard' and 'soft' and group all hard materials in one and all soft in the other?

Share this post


Link to post
Share on other sites

Well, most propagated sound definitions can be inherited, can't they? The initial work is admittedly tiresome, but it's mostly copy&paste work, isn't it?

 

Coding a solution for such a problem takes presumably longer than that.

Share this post


Link to post
Share on other sites

I don't mind doing it if that is the way to do it. It just 'feels' odd to make so many definitions which will all be identical in values (well, two divisions of them.) I just don't want to do it if afterwards I'm told 'Oh no you shouldn't have done it like that' ;) So I'm doing it step by step and someone stop me if I'm going the wrong way. So my first step is to compile a complete list of surfaces. From our wiki I get these. I assume I can exclude ricochet and plastic. Any others? And what about surftypes?

 

metal

stone

flesh

wood

cardboard

liquid

glass

plastic

ricochet

surftype10

surftype11

surftype12

surftype13

surftype14

tile

carpet

dirt

gravel

grass

rock

twigs

foliage

sand

mud

brokeglass

snow

ice

squeakboard

puddle

moss

cloth

ceramic

climbable

slate

straw

armor_leath

armor_chain

armor_plate

Share this post


Link to post
Share on other sites

In principle, the code accepts any material in the first word of the "description" string of a shader with surftype15, plus the ones defined by vanilla Doom 3 ("none", "metal", "stone", "flesh", "wood", "cardboard", "liquid", "glass", "plastic", "ricochet").

 

The ones TDM intended to add are these: "tile", "carpet", "dirt", "gravel", "grass", "rock", "twigs", "foliage", "sand", "mud", "brokeglass", "snow", "ice", "squeakboard", "puddle", "moss", "cloth", "ceramic", "slate", "straw", "armor_leath", "armor_chain", "armor_plate", "climbable", "paper"

 

There are 4 of these which are currently unused by our shaders so far:

 

cardboard

plastic

ricochet

glass

 

All the others are at least used by the tdm_collision_* materials.

 

Forget about surftypes.

 

Generally, if the workload appears to be absolutely abundant and impractical (I don't know yet, how many of those can be generally defined in the base entityclass), come back here.

 

Or let's do it that way: tell me exactly what you are about to do, maybe I can spot an easier way for me to facilitate the workload. Which spawnargs are you going to add to how many entityDefs?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...