[FREE] Precision Surface Effects (Collision/Footsteps Sounds/Particles) - Beta

This is a (free) footsteps and collision system I'm working on. It's in beta.

The features include:
- Footsteps, albeit you'll probably have to do some coding because the example script is designed for a specific character controller configuration (from unity's standard assets).
- Smoothly blended (using the terrain's alphamaps, or a component for meshcolliders (creating the normalized textures is quite difficult though)).
- Impact, friction, and vibration sounds
- Speculative impacts, which accurately finds impacts in OnCollisionStay. This is also necessary for "Continuous Speculative" which can have (0,0,0) impulse in OnCollisionEnter.
- Once set up, it's quite easy to use, because the simplest fallback sampling attempt searches material names for keywords you specify, meaning if your materials are already named properly it should kind of just work. It is quite complicated to set up though, especially the CollisionEffects and SurfaceParticles components, but that's mostly to give as much control to you as possible.
- More

There is still some outdated stuff in the wiki, but it should be helpful: https://github.com/Steffenvy/Precision-Surface-Effects/wiki

The build shown in the video can be downloaded here: https://github.com/Steffenvy/Precision-Surface-Effects/blob/master/PSE Test Build.zip


MIT licensed, you can download it here: https://github.com/Steffenvy/Precision-Surface-Effects

 

It should be compatible with unity versions earlier than 2019's. Works with the latest versions as well.

Basic testing, 1000 sound sampling iterations, debugs disabled, reusing RaycastHit, approximate average time in milliseconds:
- MeshRenderer as child of Box Collider, (using SurfaceTypeMarker out of necessity): 3 MS
- Box Collider

- Blend Marker: 1.6 MS
- Material name: 8 MS​

- Non-convex MeshCollider

- SurfaceTypeMarker (fallback) attached (found using SubMesh's material name): 2.5 MS
- SurfaceBlendOverridesMarker (whether override exists or not): 2.5 MS
- SurfaceBlendMapMarker: 8 MS
- Without any marker: 11 MS​

- Terrain: 5.2 MS


Adding any marker component will increase performance, because it can:
- Exit after an earlier successful test, instead of trying and failing several methods before finally being successful
- Faster access to components and information, which is cached inside every marker. Without a marker, it can be up to 3 GetComponents (Marker, MeshRenderer for sharedMaterials, MeshFilter for submeshes). The SurfaceTypeMarker is the best if you don't need any special control, and you can always give it a fallback string reference such as "grass", instead of the fallback being the first material's name.
- However, because the markers cache things for performance, if you ever change the materials/mesh you should do GetComponent<Marker>().Refresh() and/or RefreshSubmeshes()

 

Things I'm planning on adding/changing:

- Big list of lots of tiny things, mostly testing and potential bug finding. Considering how many bugs I find every day, that's why this is in beta, also I don't like the idea of being the only one with input.
- User data
- Point velocity calculation for accurate speeds
- ContactPoint convex triangulated mesh option for the particle shape: for particles spawned properly from e.g. a rectangular contact area.
- Submit (free) to Unity's Asset Store
- Try to optimize further
- Some way to allow both rolling (sphere, capsule) and non-rolling (box, mesh) colliders for one CollisionEffects
- Find the cause of crashing at super high speed and acceleration (grabbing one of the big boxes and scrolling back and forth):

0x00007FF630285593 (Unity) FMOD_Resampler_Linear[/INDENT]

0x00007FF6302A7179 (Unity) FMOD::DSPWaveTable::read

0x00007FF630239339 (Unity) FMOD::DSPFilter::read

...

​

Things I might change/add:

- Decals perhaps
- AudioSource pooling with prefabs
- Change some slope controls to curve controls - for example maybe a square root standard for volume (particularly vibration volume) so that huge and tiny impacts can both be heard on a single big object (instead of scaling the forces to prevent absurd volumes when its own large mass (therefore large force and therefore large volume) is concerned).
- Dynamic vibration origin (but I think the teleportation would be a problem for doppler)
- Dynamic friction/impact origins - For impact it might require audio source pooling
- More particle control perhaps, it's not very realistic at the moment.
- Sound Overrides (the sound equivalent of SurfaceParticleOverrides.cs). Sounds generally don't vary as much as apperances (textures/materials) do, also, splicing using Blends should allow quite some nuance. But it's also not very scalable to require a new SurfaceType just for a single outlier's sake.
- Performance optimizations, for example I don't know whether there's an overhead every time I access a (non-garbagey) property in a Collision. Also, I could probably do more System.Object.Equals(, null) instead of Unity's fake-null checks (e.g. would unity return a fake-null object in GetComponent?).
- Base component with 2 SoundSet variants, one used if the surface has a vibration sound, and one if the surface doesn't (with vibration sound baked into the Audio Clips).
- Web player build. Already tried it but the audio was very poppy. Don't know why.​

Things I probably won't add/change:

- Auto-upgrading from previous versions (if let's say I change some serialization structure, then sorry).
- Terrain vibration sound (that would just be so complex to do). Also, terrains aren't usually made of very resonant materials like metal, plastic, or wood.
- Sliding/Rolling sound distinction. The singular friction sound should be alright though.
- Good audio clips (find, make, or buy them yourself. They're actually quite difficult to get). Especially make sure that the friction loops are long
- ECS support. It feels like it would be very difficult to implement, although multi-threading would be a good thing for this (since the performance isn't amazing).
- Volumetric Audio Sources. Wouldn't know where to start, but I certainly wouldn't like to make a native audio plugin for it, so it would probably be an integration with something that already exists
- There is quite a frustratic perspective when it comes to CollisionEffects, a lot of the settings would make more sense to exist in the SurfaceTypes than the CollisionEffects, but at the same time their existence in CollisionEffects allows balance and compromises for an imperfect physics system; Therefore the best case would be to add them to both perspectives, but that would be very chaotic. PhysX is at fault for not being more physics property material oriented, although the alternatives to it don't seem they would be much better for this from what I can see.
- Support for other physics or game engines.
- Self blending (all sounds/particles are found using a distinct SoundSet/ParticleSet. You can seperate the children of a compound collider using a CollisionEffectsParent component, but I feel like it would be a terrible idea to allow blending from both the collider and collidee. In all likelihood you won't ever need to). But if you do, I guess I could expose some temporary weights for you to give while handling the OnCollision callbacks yourself.
- Faster SurfaceType finding (without using string.Contains). But for convenience and scalability I'd like let's say the keyword "Tile" to be interpreted differently if desired, perhaps it sometimes means something different than "Stone". I would like to avoid a single standard (ie a single SurfaceData + caching the surfaceType IDs).​

 

Hi!, this is wonderful!

Could you use it in commercial projects?

Thank you very much for sharing and great work!

Best regards

 

Sorry for the huge delay, I didn't receive an alert. But yeah it's MIT licensed so it can be used in commercial projects