What can be achieved with just two speakers* is really quite amazing. It's not working / implemented in Empyrion though. I have used more sophisticated multi-speaker (aka surround) systems and they're great. They're just not practical in the space I personally have available to me. So, two speakers - or a set of headphones if I need to keep the noise down - works perfectly fine. Even my TV, which is using the built-in speakers - which actually face the wall - does an amazing job of making the sound seem to be coming from all around me. Bloody clever stuff. I don't game on this TV, it's just for Movies and TV Shows. As mentioned, plenty of other games I play over the exact same hardware audibly communicate that something is behind me pretty darn well. Empyrion can't even get left or right correct half the time lol. Bottom line: Empyrion's audio is not proper 3d audio in the widely-accepted sense. Well, if it is 3d Audio, someone got the positioning very very wrong. Aka: this is a software issue, not hardware. Two speakers * are plenty for this to work pretty darn well. Back to my original point, having the positional sound working, makes many aspects of the game harder, as I rely heavily on audio cues in any sort of first-person environment. * My speakers / headphones might just appear to be two speakers but, as mentioned above, there's a bit more to them than that.
You're assuming more than I'm saying. I'm not making some grand generalization. Empyrion specifically has problems stemming from not properly utilizing available audio tools.
This is all you had to say in the first place; it is an accurate observation and we all agree on this. The other details you laid out as to why and how this occurs are largely incorrect, which is what prompted my response. If we're going to bother with breaking down the design and attempting to dissect everything at play here, we should get the facts straight. As I'm not a sound designer who regularly works with Unity, I don't have much additional knowledge to offer on this. But if I'm going to pull a few speculations out of thin air, I'd make these two points. 1. I wonder if (and if not, why?) the same logic for culling visually obstructed NPCs does not also apply heavy muting to their sounds (growling, footsteps, etc). Or maybe just use an NPC's line of sight targeting as the trigger. Example: if an NPC can see the player, their sounds are at full volume, otherwise 30% plus whatever other distance based dropoff they have. 2. I'm confident someone else has made this point already, but the volume drop off for growls and such seems too low. I think it should be only at full volume when they're within kissing distance, but drops drastically within the first 3 - 5 meters, then more gradually to the maximum distance. But that's all just from what I remember and I don't often do POIs. I'd have to do some POI run-throughs again before saying much else.
This would work if both the origin and listener are static but that's about it. Now, you could use raytracing to simulate sound waves bouncing around corners/through doorways etc. and use that to apply attenuation but that would probably be a bit more performance intensive than most people would like. Also if blocks had a 'density' property you could calculate how sound transmits through them. There is just no way to do this believably without a bunch of real-time math. It might be posable to optimize the formula enough to work in situations where the player is in range of 50+ sound sources without bringing a modern computer to its knees. Keep in mind that Empyrion is already a bit of a performance hog as it is. Sound drop-off (attenuation) is actually really easy to calculate. Its literally just the square of the the distance. No need to use arbitrary numbers for drop-off. If the drop-off still isn't enough (or is to much) you can apply a simple multiplier to it. Or it guess you could clamp the value but that would be almost as bad as what we have now.
Unity's default audio system (Native Audio Plugin SDK) can simulate the Head-Related Transfer Function (HRTF) described in the explanations from my previous link. This means that, if implemented correctly, spacialization should allow hearing sounds from where they are emitted correctly, at least on a same horizontal plane, with very basic headphones. For more control over spatialization, it is required to use the Audio Spatialization SDK, which supports effects (reverb, doppler, etc) to enhance realism: https://docs.unity3d.com/Manual/AudioSpatializerSDK.html Unity uses sound sources (ex. attached to mobs) and Sound Receivers (the player, AKA the camera) and then tracks the motion of the receiver (camera) to calculate how to simulate the HRTF while the receiver changes position / angle. This requires working with several matrix transforms to follow rotation / position, and can become quite CPU intensive or sound can lag. Some examples are given in the link above. The problem with sound in POIs would probably be the same as the AI navigation problem Eleon had to solve. POIs are not pre-built with nav meshes included, which usually contain the geometry that the AI relies on to make paths for critters, so Eleon had to invent its own solution. I guess they can find a similar solution to allow enhancements in player built POIs, like adding reverb or echo (delay) in large rooms.
What I personally don't understand is why the sound attenuation for walls is non-existent. For the simplest implementation, all you have to do, as a programmer, is to count the number of solid blocks between the sound emitter and receiver. You already have an array of structure's blocks at hand. You have the emitter's and receiver's coordinates. There is ~30 emitters and ~5 receivers at any given time. The calculation is mathematically and algorithmically trivial, and should only be done at either a fixed rate (10 fps for sound should suffice) or, if you want, on such a coordinate change that changes the number of blocks between the emitter and the receiver (which is, again, a trivial calculation). Why is it so hard?
There is no need to dive into such elaborate programming just for the sake of immersion and pseudo-realism. First, 2 meters of concrete or metal (BA blocks) would render any sound imperceptible, apart vibrations from heavy machinery and explosions. So any sound from another type would simply be muted by the thickness of the floor, and by most of the walls in POIs. In most games, the ambiance is setup with simulation : distant shrieks and yells, moanings, etc, which are impossible to locate apart from the feeling that they are emitted too far to be concerned of danger in the immediate vicinity. They are deemed to be reflected and propagated through long corridors and vents, etc. For anything else of concern (close by) games rely simply on range and line-of-sight. If the player is in range horizontally or in a large room spanning many floors vertically, then the critter's detection range applies and 2 types of sounds can be played (for example) : 1 muffled, "idle" sound if no line-of-sight with the player, and the same "idle" sound with no filter if player can be seen but is not in the visual cone of the critter. This would be way more simple to calculate and implement, with minimal performance cost. Ambiance would also feel more immersive with simulated distant sounds like described previously, while they don't need to rely on any critter location (or not yet spawned) else than what is of real concern for the player in close proximity. These simulated sounds can also be "spatialized" since they can be emitted in the same area the player is in, tied to invisible and static entities around the player.
Its actually even simpler then that. You just draw a line between receiver and emitter then count the object the line intersects. The raycast function would be the place where I would start building code to do this. No need to walk the array of blocks at all unless you need information that isn't stored or referenced on the blocks object. Unfortunately the basic problem your trying to solve is not that simple. Take these two rooms for example: A = an Abomination (Horror) p = Player standing in front of open door Code: ------------------------- | | | | A | | | | | | | | | | | | P | ------------------------- If you draw a straight line between the mod and the player, the sound would pass through 3 block. So you would be applying additional attenuation 3 extra times when you would expect for the sound to attenuate only slightly more then if the mob were standing three blocks away with no intervening blocks. You would also run into weird situations where a mob just around a corner sounds muffled and then is at full volume when it rounds the corner a split second later and there would be edge cases involving rooms with pillars and such.
Because sound reverberates everywhere, I would not even start taking any block into account in this case since the door is already opened. If door closed = play muted sound (no line-of-sight). Line-of-sight should be defined as a way for sound to travel to the player. A raycast function would need to have defined "bounces" on surfaces (like raytrace) and this is too costly for a game.
We're on the same page here. The game already suffers from poor performance, there is not much room left for fancy programming. Simulating distant critters would allow to lower their sound's volume without any spatialization fidlling, and players would not even notice a difference.
I'm perfectly content for the game to use any "cheat" (aka low-resource-cost) methods to make the sound appear more realistic. No need for a hard, ray-traced implementation for audio here, just some logical alterations to the sounds, which have pretty much been covered perfectly above. Make me believe that a sound is distant and trivial, make me believe it's coming from behind that door (door "blocks" less sound than wall), make those faint scratching sounds from beneath the floor sound like they're muted appropriately. Plus, of course, make me able to tell if a sound is coming from the left or right of me. Considering how positional sound is an integral component of many a game these days, it is important to get things right. Regarding performance in general, I thought the game was generally fine in single player currently, but the usual issues would arise with multi-player. While lots of assets "live" at one time - POI's, Drones, Patrol Vessels and multiple player assets can cause issues, I thought it was the network code that was generally considered the weak link. I have zero knowledge about this, just what's been mentioned on the forums / in videos etc.
One more thing worth mentioning... Eleon have added visual indicators to the screen fairly recently to help indicate from which direction the player (on foot or in a vessel) is being shot from. This doesn't replace accurate sound of course, but should be a great help...in theory. I've noticed, from time to time, situations where the damage indicator is not accurate. I.e. I'm shown as taking damage from my 11 O'Clock, but the Sentry shooting me is actually at my 3 O'Clock. Obviously the potential confusion caused by this can lead to the player taking even more damage. Currently, as the sound does not correctly inform me of where fire is coming from as it should, I generally just retrace my steps if I come under fire and cannot quickly identify the source. With the visual damage indicators, I can waste a moment turning towards where the damage visualisation shows the fire as coming from, only to find out it's not correct. This relatively new addition to the game, while welcome and having the potential to work-around the sound issues to a degree, is sometimes a liability. Still, as a newer feature, hopefully it will get further refinement.
I didn't say "walk the array of blocks", especially with the meaning "iterate over all of the blocks in the structure". And the 'raycast' function works with colliders, which may or may not be present for the blocks the structure is composed of (bc some optimizations, like situationaly merging blocks' colliders or not having colliders for the inner surfaces come to mind). I just said that all the information needed is right there, the developer has everything that he needs for this simple algorithm.
That is correct. But the improvement over the current "sound everywhere" system is that we would get weird results less frequently than non-weird ones. And that should count as an improvement, because otherwise, why not just mute all the sound, if we can't implement a system that yields perfect results? That'd be funny, if the devs haven't already headed that way with the bike. So, I'm expecting no in-game sound by 2024.
Unfortunately, even in completely static levels, this requires a good amount of work to be done correctly. I remember playing Far Cry 2, specifically, the native shacks made out of mud bricks. They were small and had an open doorframe and open windows, and walls ~10 cm thick. Yet, due to the space inside them was marked as "inside" by the level designers, a hilarious sound bug ensued. The enemy gunmen would chase you to the shack, and fire at you standing directly beside the window or the doorframe (sometimes with the muzzle of their gun actually inside the shack). Yet, as you were inside, and they were outside, the sounds played were heavily muffled. That would've never happened had the game engine checked if there is a line between me and the goon. Knowing the destructible nature of structures in Empyrion, and knowing that even a static level game screws this up royally, I wouldn't recommend this method of sound attenuation.
Quite the opposite: it seems to me that the lack of fancy (as in, sophisticated, skilled, far-planning and well-structured) programming is what results in poor optimization. Because it usually does. Add an algorithm that correctly decides where and when to apply this simplification, and that would be a good example of a "fancy" programming technique.
Fancy can also mean whimsical, elaborate and capricious. A poorly written program can absolutely be optimized. I fail to see what you are trying to make of what I wrote. If we use your restrictive definition : sure. In the very first of your posts I replied to, where you asked "Why is it so hard (to implement)?", I could have simply replied : what do you know about attempts (if any) by Eleon to solve the problem, and the difficulties encountered ? Your proposed "solution" sounded like anything but efficient and reasonable for a game already suffering from poor performance. It sure looked the same to at least another player who replied to you. Maybe you were just trying to say "Eleon is a bunch of incompetents" and you thought I just did not get it ? Feel free to enlighten me. In the specific case here, my use of the words "fancy programming" were aiming at the proposed counting of blocks to determine the amount of muting that should be put on sounds, and that is overkill and costly for the situation.
You mean using something like a 3d Bresenham? Sure that would work, assuming that block data is actually stored in a 3d array and not just all randomly jammed into a single huge array or linked list. I also found this java code that looks like it would do what your talking about. Both would be fast and if it were only ever run every few frames for the duration of a sound it would probably be fine. Assuming the best case scenario and the dev managed to write bug free code that didn't break ever time they update the game. But that's making a lot of assumptions. As for raycasting...your right. I forgot they now have occlusion culling. I disagree. In the example I gave, the mob would sound like it was 3 times further away then it actually was. That's one third the time to react then one would expect and that's bad. Simply using Unitys built in sound API properly to get true directional sound with working basic attenuation would be enough to 'fix' the games sound problems. They would and they have. I remember a time when you could set a structure you owned to public right in the p menu. That was removed because public structures don't receive base attacks so it was considered an exploit. Why fix a problem when you can just wall it off. I wasn't very nice when I read that in the release post. Also make sure to open the spoiler in my signature. It's relevant. === Edit === Taking a look at the documentation for AudioSource two things come to mind for mob sounds based on my limited testing: It sounds like they have minDistance set really high. Like around 30m. spatialBlend sounds like its set wrong. This should be set to 1. Also, I don't understand why you would want to morph between 2d and 3d sound but whatever. I don't really understand what AudioImporter is or how its supposed to be used with AudioSource. It would be fascinating to see Elions source code...
Okay, I'll put it plainly, using simple terms. The fact that a software is struggling with performance as it is doesn't mean that advanced algorithms are now forbidden. It means that there is a lack of advanced algorithms, which leads to poor optimization. I kindly advise you not to put your words in my mouth. "a bunch of incompetents" is your wording. Since you asked about what I think of Eleon, even in this ill-assuming way, I will tell you. I don't think of Eleon as a bunch of incompetents. I think of them as a once (few years back) very enthusiastic group of indie developers, heavily understaffed with programmers specializing in high-performance applications. They had a vision of a great game, and their enthusiasm and hard work had got them this far. But, over time, it seems to me that, with coding problems accumulating, in-game problems, bugs, and unpolished features started to pile-up. And the inability (despite multiple trial and error, and, I believe, honest hard work) to overcome them, these problems started to take their toll on the enthusiasm. I wouldn't have bought this game if I didn't see the progress it made in prior years. But now, the progress has slowed down dramatically. And the root cause, as I see it, lies in coding. I specifically explained why it is, in fact, efficient. I'll repeat myself. That is because there are about 5 sound receivers and a few tens of emitters in a playfield simultaneously. That gives around few hundred emitter-receiver relations, each of which is trivial to calculate, because in a cubic structure, it is that simple. Hell, it could as well be calculated on a client machine, and that is precisely one receiver. If we are to use the simple algorithm counting the blocks, it's a joke of a task for a 4 GHz processor, if implemented correctly. If you think otherwise, please, "feel free to enlighten me", citing your own words, how exactly is that not efficient, and is .
