Fett263 is doing some experimenting with measuring hit strength in ProffieOS 6.*. However, that got me thinking about what the the correct way to measure hit strength is.
Is it…
- The speed of change in acceleration:
(acceleration - previous\space acceleration)/time\space between\space measurements
- The actual acceleration: |acceleration - down|
- Area under the curve: \int|acceleration - down|dt
- Swing speed at the time of impact
I kind of think it’s either 2 or 3.
To put it a different way, should the sound be equally loud if you hit something hard (quick) or something soft (longer impact)?
Interesting concept here. Is there a way to measure it by vibration? A smaller impact will cause the blade/saber to vibrate ever so slightly…where as harder impact create more felt vibration on the saber.
***edit- this wont work, because it will trigger AFTER the impact has already took place, nevermind.
If not, i’d opt for #2 above.
Another interesting thing to do if this is something to be explored, is to dedicate certain font wave files for impacts that fall under certain thresholds. Like ‘clash_soft’, clash_med’, 'clash_hard". This way for extreme impacts you can dedicate sound files that sound more explosive, where as smaller impacts can sound different with subtle nuances.
Vibrations show up as back-and-forth acceleration.
It’s entirely possible to measure, but it takes time to do so as it takes many acceleration measurements to identify vibrations.
As for the font thing, the idea would be to pick higher number files for higher clashes. There would also be a random component to the selection and the font config file would specify the balance between the randomness and the hit strength.
Also, we can adjust the volume of the clashes based on the strength.
That might actually be easier, because we might not now how strong the clash is until a couple of milliseconds after we’ve started playing the sound.
***edit- the vibration method actually might not work effectively, because it will trigger AFTER the impact has already took place to take the measurement and it may put in unnecessary processing power to calculate something that quickly (after physical impact, but before the sound is played) before playin the wave sound.
but im no expert in this kinda thing, so I trust you know whats best optimally.
So far i like your option #2
This is a 3d-plot of the acceleration a stab.
The two larger blobs indicates where the clash was detected.
(Using the old method which measured differences between adjacent measurements.)
You can then see a lot of the vibrations as the acceleration returns back to the down vector.
I’m not much use here. I’ll just say that in my mind, the ideal way to handle font sounds would just be the equivalent of velocity sensitivity in a MIDI keyboard. Drive the volume based on the strength of the hit. How you guys math that part out…I’m a quiet observer.
1 Like
The mechanics inside velocity-sensetive keyboards also vary a great deal between keyboards.
Piano keys (which is what a velocity sensetive keyboard tries to emulate) doesn’t have to worry about hitting things at an angle, or hitting soft/hard targets. Also, you don’t usually swing your keyboard at stuff.
In a piono, how hard you press the keys determine how fast the hammer accelerates. The speed as it hits the string is ultimately what determines the strength of the clash. On a saber this would be equivalent to the swing speed. If all clashes where controlled and straight-on like in a piano, this would probably work pretty well. But it wouldn’t work well for a glancing blow. In that case, the saber is moving very fast, but the clash is really minor because it hits the saber at an angle. It also wouldn’t work well if someone else hits your saber while you’re holding it still.
1 Like
It’s been suggested that (acceleration - down)^2 might be a better representation of hit strength than option (2) in the top post. I’m not sure why that would be though…
Just seeing this thread, I’ve actually been testing this quite a bit over a long time. In my tests I’m using a SmoothStep that takes up a % of the blade based on how hard the blade is impacted. I have gone through several iterations of ClashImpact<> function but the one that produces the most consistent for me was diff.len2() (I think that’s the function, I’ve been doing the math in the function itself to this point). What I was finding is diff.len() would occasionally produce a very low value on a very hard hit and/or a very high value on a relatively lighter hit, the diff.len2() has this happen from time to time but in tests it happens noticeably less often. Not entirely sure the “real world” cause, it’s just been an observation over a very many tests. In the end I’m open to the best results. The intent I’m chasing is for Clash and Begin Lockup effects that are based on the actual impact on the blade. For the effects/function side I do have a solution that is working very well. I’ve also been chasing having the sound of the clash.wav and bgnlock.wav be “Scaled” based on the hit with a little less success. I’m still sorting the sound side out but the function side has been working well for a little while now, but I’m open to making it even better.
1 Like
Bt there is a problem with this observation.
Using len() or len2() can’t really affect the reliability of the result, it can only change the scale of the result. That either means that your observations are random, or that they correlate with something else in the code.
I can’t say definitively, it’s just been more consistent with current calculations, maybe earlier versions had issues elsewhere in the code. I can try swapping out diff.len() and diff.len2() and leave everything else as is (would need to re-scale) to see if it’s still true. The original iteration was back late last year and I picked it back up recently with some improvements to try to prep it for OS6, so it’s entirely possible there was an unseen factor when I was using diff.len() that skewed results. I’ll try out some A/B tests and report back and try video if there are still differences to show what I’m “seeing”.
1 Like
