Astronomy and optics wins! Incorrect skybox color tint is finally slated for fixing.

There's way too much sound in this game. It's not like real space, and It's jarring. I'd like all the non-cockpit sounds removed from the game entirely, so It's more realistic.
The sounds are meant to be generated by your ships computer, as a sensory aid for stuff you can't see (e.g. enemies and attacks from the side/rear). I guess by the 34th century we won't only use visual cues...

Thanks for that! Looks massively better without the silly snow. Might have to put it back in normal space though unfortunately, it helps indicate my velocity in combat. I'll see how I get on.
Makes more sense in Supercruise as an artefact of the space distortion from the drive.
 
It's hard to define which sounds are non-cockpit. For example all sounds produced by your weapons, drives and fsd, can be legit sounds of corresponding aggregates in your ship. All sounds produced by hits to your ship (both from weapons and collisions) can also be legit sounds caused by vibrations of the hull, or shield generator (did you hear how high-voltage electric coils can "scream" and "cry" :D ). Of course, unless you state that there is complete vacuum in the ship except the cockpit room. Though even then sound can travel through solid constructions and be audible in cockpit.
I can hardly remember any sound in ED, which wouldn't have at least bare explanation in the approach of being produced by hull/ship aggregates.

By the way, i really hate "ambient" sound on system and galaxy maps (they cannot be disabled without complete sound turning off, they exist even all the music is disabled).
 
Last edited:
It's hard to define which sounds are non-cockpit. For example all sounds produced by your weapons, drives and fsd, can be legit sounds of corresponding aggregates in your ship. All sounds produced by hits to your ship (both from weapons and collisions) can also be legit sounds caused by vibrations of the hull. Of course, unless you state that there is complete vacuum in the ship except the cockpit room. Though even then sound can travel through solid constructions and be audible in cockpit.
I can hardly remember any sound in ED, which wouldn't have at least bare explanation in the approach of being produced by hull/ship aggregates.

By the way, i really hate "ambient" sound on system and galaxy maps (they cannot be disabled without complete sound turning off, they exist even all the music is disabled).
While the ambient sound on maps isn't that bad for me, I would love options for toggling scientific stuff on and off. Like the sounds for example. A toggle for a more realistic approach where there is no sound in space and whatever happens to your ship is muffled for example. Options for turning off the space dust and instead a HUD indicator telling you which direction the ship is moving (that was a thing in Frontier and First Encounters) for FA off flying. Things like that.
 
The sounds are meant to be generated by your ships computer, as a sensory aid for stuff you can't see (e.g. enemies and attacks from the side/rear). I guess by the 34th century we won't only use visual cues...
If this is the case, each different ship should have a different tone (stacked) so a trained pilot could tell how many ships are in the area by sound alone. Not the case in ED. A C3 sounds like all the others, no differentiation are made when there are more than one craft in an area.

It's a game. Has some SIM elements, still largely a game.
 
Hi Old Duck :) - that's probably more to do with the object hierarchy further down the chain, in 3D space. The main benefit of post-processing shaders is that they're fairly cheap in computational terms since you're just working with and on pixel data. There's no way to cleanly discern different objects in the scene as you could with 3D data. It's comparable to committing a 3D scene to film and then applying filter effects in editing software. You can pass variables from the game to modulate the filters in real-time so it's quite powerful (distance from star etc), but the filter itself is only ever applied to pixel data. If they could do it with whatever method they're using, I'm sure that they would have addressed some of the dimming issues on the HUD and so on. I've not used GLSL in a game development context so their implementation might be more sophisticated than I'm suggesting, but that would kind of defeat the object of using them, which is fairly dynamic and dramatic effects at modest computational cost. It certainly looks like a plain old set of 2D filters applied at the end of the pipeline to me.

P.S If you examine the images above you can see that every element on-screen shows the signs of being shifted towards a given part of the colour spectrum. I would much prefer a more natural looking Milky Way, but for me the unnatural effect that it has on the HUD is the more disconcerting.
I think your point about computational cheapness is well made but the skybox, once generated, should be an easy and cheap thing to handle separately. The skybox itself is a generated texture (based on the current location) and it's rendered projected onto the inner surface of an infinitely-distant sphere. At this point everything that needs to happen to it - and ONLY it - can be done with 2D filters. Overall dimming based on the local ambient intensity, nebula "fogging" (also astronomically incorrect but way more acceptable than tinting from the local star) - All these things are being done already, they need no increase in computational resources. Likewise, everything required to render "local" objects is already being done and it would be no more computationally intensive to render them down to 2D space with a transparent background and apply all their appropriate 2D filters. The only increased need for handling the skybox separately would be the memory to buffer an additional 2D layer and the computation to composite the layers after all 2D filters had been applied to each. There would be no duplication of shaders or other rendering steps. In the case of the skybox and local objects, the sets of 2D filters would have no overlap - there would be no cases in which you'd have to run the same filter twice on two different buffers, and if you did have a filter that had to run on the entire 2D image, you'd just move it to happen after compositing.

In fact, this approach could even address your legitimate gripe about HUD tinting too. If you can composite 2 2D images, each of which has had its own appropriate set of filters run, why not three? The three sets of 2D effects would be the three completely distinct sets of conditions Layer 1: Distant emissive (skybox) Layer 2: Local system and objects, including ship exterior, with no background. Layer 3: Ship interior with no background. No need for depth-mapping, layer 1 is ALWAYS behind everything else, layer 3 is ALWAYS in front of everything else, so it's simple 2D compositing of the layers. This would be more complex than for just the skybox but once the basic structure had been coded for rendering separate layers and compositing them, probably not too burdensome to expand to that level.
 
I think your point about computational cheapness is well made but the skybox, once generated, should be an easy and cheap thing to handle separately. The skybox itself is a generated texture (based on the current location) and it's rendered projected onto the inner surface of an infinitely-distant sphere. At this point everything that needs to happen to it - and ONLY it - can be done with 2D filters. Overall dimming based on the local ambient intensity, nebula "fogging" (also astronomically incorrect but way more acceptable than tinting from the local star) - All these things are being done already, they need no increase in computational resources. Likewise, everything required to render "local" objects is already being done and it would be no more computationally intensive to render them down to 2D space with a transparent background and apply all their appropriate 2D filters. The only increased need for handling the skybox separately would be the memory to buffer an additional 2D layer and the computation to composite the layers after all 2D filters had been applied to each. There would be no duplication of shaders or other rendering steps. In the case of the skybox and local objects, the sets of 2D filters would have no overlap - there would be no cases in which you'd have to run the same filter twice on two different buffers, and if you did have a filter that had to run on the entire 2D image, you'd just move it to happen after compositing.

In fact, this approach could even address your legitimate gripe about HUD tinting too. If you can composite 2 2D images, each of which has had its own appropriate set of filters run, why not three? The three sets of 2D effects would be the three completely distinct sets of conditions Layer 1: Distant emissive (skybox) Layer 2: Local system and objects, including ship exterior, with no background. Layer 3: Ship interior with no background. No need for depth-mapping, layer 1 is ALWAYS behind everything else, layer 3 is ALWAYS in front of everything else, so it's simple 2D compositing of the layers. This would be more complex than for just the skybox but once the basic structure had been coded for rendering separate layers and compositing them, probably not too burdensome to expand to that level.
I'd be happy with simplest ability to just disable this post-processing completely via options, or even via graphic options xml. To my pity i didn't find anything like this so far (yes, setting PrototypeLightingBalancesEnabled to 0 doesn't help at all with colors tinting).
Actually i hate any kind of post-processings in any games. I disabled idiotic green tint in fallout3, sepia tint in deus ex, bloom/blur/filmGrain/vignette ultimately in all games always. If game doesn't allow to disable them, i just skip it completely.
Because i want to feel myself as much as possible being "inside" the game, like in real life. And suddenly, we don't have sepia tints and film grains in our eyes in real life.
I hate vfx designers who put these filters into games without possibility to disable them, saying "i'm designer, i better know who people must perceive the game". Give me just a clean source image and let me decide how i want to perceive it.
 
Hmmm going to have to add to saying it is Acknowledged is not the same saying it is going to be fixed.
 
A toggle for a more realistic approach where there is no sound in space and whatever happens to your ship is muffled for example
There is a mode for that - just turn off your Life Support! (y)

No - seriously. Get an A-class Life Support system and fly around with it off. It sounds exactly like what you want, and for most things will last you plenty of time between stations - even exploration runs if you save up enough materials.
 
The sounds are meant to be generated by your ships computer, as a sensory aid for stuff you can't see (e.g. enemies and attacks from the side/rear). I guess by the 34th century we won't only use visual cues...

Makes more sense in Supercruise as an artefact of the space distortion from the drive.
It was in 3307 that Humans first heard a Thargoid Interceptor in an atmosphere thick enough to convey the true sound, and discovered their own guess, that pilots had been 'hearing' for years was wildly inaccurate, and that Thargoid ships sounded like four continuously deflating woopee cushions.
 
Devs deciding to fix an issue with indiscriminately implemented lighting effects – a victory for the science history books... :giggle:
 
Last edited:
Top Bottom