All fast vector maths and GPU work is still 32-bit floating point (down to hardware, not choice), besides which the released version of Elite is currently 32-bit anyway.
Anti-Aliasing does not function
- Thread starter Nate--IRL--
- Start date
This has nothing to do with 32- vs. 64-bit addresses; it's just that with the vastness of space in the game the floating point precision used for 3D coordinates is not precise enough that the station rotation doesn't introduce a slight jitter, which wreaks visual havoc combined with the aliasing in certain geometry.
Its a gfx card/driver problem, not a cpu/address space problem. Even though an application may be 64bit, the realtime display of that data in 3D space will be single precision, specifically the problem here is the rotating station structures constantly dragging you through a 3D grid of coordinates. In my experience the only reasonable solutions here are changes to geometry or shaders to reduce the issue, but so long as the structures rotate in space there will always be a certain amount of shimmering.
I agree with the guy somewhere above who says it's a psychological factor.
Essentially, what I think is happening is that the AA is working fine, it's just that there's so much rectilinearity in the game (compared to your average game that has big blocks of colour, rounded organic contours, and rarer rectilinearity) especially in stations, that the kludgy nature of AA in general is shown up more and there's more shimmering effect all over the place. Really the only solution to it would be to have two beastly graphics cards in a beastly computer, run the game at the highest possible resolution AND have SSAA (the best but most computationally expensive form of AA) on top of that. (But we'll all probably have access to something equivalent a few years down the road
)
It's not a perfect process folks, in none of its versions (FXAA is computationally cheap but awful, MSAA is decent but computationally expensive, SSAA is quite good but ridiculously computationally expensive, SMAA is a good all-round compromise in that it's nearly as cheap as FXAA, but much less blurry, but it's still not quite as good as either MSAA or SSAA). The only AA that really gets rid of "shimmering" to any great degree is Nvidia's TXAA and that has to be specially supported, and is still a little blurry like FXAA/SMAA).
Bear in mind, nobody's seen space sims for years, nobody's seen a working game space sim for years with modern graphics, and the older "classics" were either pixellated anyway or graphically simpler, so it's a new phenomenon - I think it just happens to be showing up the poverty of most AA solutions.
But not to worry, as I said, the hardware will improve anyway, and eventually SSAA will have an unnoticeable effect on framerate.
Essentially, what I think is happening is that the AA is working fine, it's just that there's so much rectilinearity in the game (compared to your average game that has big blocks of colour, rounded organic contours, and rarer rectilinearity) especially in stations, that the kludgy nature of AA in general is shown up more and there's more shimmering effect all over the place. Really the only solution to it would be to have two beastly graphics cards in a beastly computer, run the game at the highest possible resolution AND have SSAA (the best but most computationally expensive form of AA) on top of that. (But we'll all probably have access to something equivalent a few years down the road
)It's not a perfect process folks, in none of its versions (FXAA is computationally cheap but awful, MSAA is decent but computationally expensive, SSAA is quite good but ridiculously computationally expensive, SMAA is a good all-round compromise in that it's nearly as cheap as FXAA, but much less blurry, but it's still not quite as good as either MSAA or SSAA). The only AA that really gets rid of "shimmering" to any great degree is Nvidia's TXAA and that has to be specially supported, and is still a little blurry like FXAA/SMAA).
Bear in mind, nobody's seen space sims for years, nobody's seen a working game space sim for years with modern graphics, and the older "classics" were either pixellated anyway or graphically simpler, so it's a new phenomenon - I think it just happens to be showing up the poverty of most AA solutions.
But not to worry, as I said, the hardware will improve anyway, and eventually SSAA will have an unnoticeable effect on framerate.
Last edited:
I disagree with you here, I never seen a game (at least games with a ego perspective etc.) that looked good with only Post Processing AA and for me ED looks as expected: Bad in motion as soon as object edges and small lines are visible. Alien Isolation is another (more traditionally looking title) with great artwork and fantastic lightning that suffers immensely from Post AA. They should have just implemented MSAA, even though it is more work compared to some years ago (but it is doable with DX10/11). 4xMSAA would look better than my mild down sampling (1440p with a 1080p display) and SMAA and use less GPU power. You could still use Post AA to get rid of shader aliasing etc. and profit from new advances like Nvidias new MFAA (basically a MSAA mod that makes it supposedly double as effective without changing the performance as long as your FPS stay high).
I understand that they had a tight budget, and needed to invest in other things. But it is still sad for me. The game looks good and performes great, but the carefully constructed space station just flicker as hell with movement. And the great performance provided by the optimized engine doesn't do much if you need to render at 4k or more to get it of the flickering.
Some minor thing though, you guys could reduce flickering of the orbital lines by just making them a bit bigger and make the edges more blurry (more transparent at the edge then in the middle).
EDIT: Small trick for Nvidia users (sure AMD provides something similar) who don't mind less sharpness. Activate ingame SMAA and force via the driver FXAA.
Last edited:
Not sure why you are being deliberately confrontational here by saying I haven't read the topic. I have. DSR IS a brute force method of anti-aliasing. And your claim of it not being an option is also incorrect. You CAN put together a pc to run whatever you want, you just need to throw enough money at it. If you don't have the money to do that don't blame me, the Oculus Rift or FD... Plenty of people are running DK2 with SLI no problem... The maxwell cards specifically support this function, and it works well, I have experienced it myself on my friend's pc running twin 980's.
Sorry to say mate but unless you know for sure what you're talking about try asking questions instead of stating untruths
- - - - - Additional Content Posted / Auto Merge - - - - -
Great tip, I forgot to mention that earlier. I read about doing this on another forum and it does work very well
Can't seem to do this on mine (GTX760) - says "not supported in this application" in control panel, and "disallowed with this application" in Nvidia Inspector.
You need to use NVidia Inspector. The stock driver control panel wont let you do it.
Maybe the bright/dark effect flickering and running across many of the straight lines in this video are what he is describing? (It is more visible in a big player in a separate tab.)
[video=youtube;2WMfsMjENSI]https://www.youtube.com/watch?v=2WMfsMjENSI[/video]
Yep thats it.
Interesting. Will there ever be potential for Elite to transition to 64-bit?
Oh yeah, got it now. I have Nvidia Inspector but I thought the "disallowed" thing meant I couldn't change it. So I allowed it in Inspector and put it to on in Nvidia control panel. Thanks for the tweak!
Is there actually a need to have such a "vast" space? No one is going to explore it all, game wont ever be populated enough to do so either.
It just seems like: Quantity > Quality.
Reduce the scope of the game, improve elsewhere, such as proper fleet/friend piloting systems, sharing missions, fixing AI twitching around in USS/Navpoints and getting stuck inside stations (prob related to coords?)
Ok take this for what its worth but I have been playing around with SweetFX settings all afternoon and it seems like the combo of SMAA and FXAA makes a nice improvement in the swimming/flickering lines.
At least to my eyes on my set up. Also tweaked the colors some to get rid of some of the red tint to everything and made it a little cooler(temp).
So here is what I am using if anyone else wants to try it. Just thought I would offer.
Unzip this SweetFX into your \Frontier\EDLaunch\Products\FORC-FDEV-D-1010
https://db.tt/rbzDkgi1
Hope this helps some for a temp fix.
Oh and make sure you turn off AA in game. Insert Key is the toggle on/off for this SweetFX.
At least to my eyes on my set up. Also tweaked the colors some to get rid of some of the red tint to everything and made it a little cooler(temp).
So here is what I am using if anyone else wants to try it. Just thought I would offer.
Unzip this SweetFX into your \Frontier\EDLaunch\Products\FORC-FDEV-D-1010
https://db.tt/rbzDkgi1
Hope this helps some for a temp fix.
Oh and make sure you turn off AA in game. Insert Key is the toggle on/off for this SweetFX.
Last edited:
I wonder if the new feature to control multisampling in the shader can be used for that.
Can you please post a little more details about this tweak? I've looked around in nvidia inspector and I'm lost about what I should set and where. A screenshot would be perfect. Thanks!
...
I'm REALLY not trying to start a flame war here, so please don't take it that way (it's hard to get meaning across sometimes on a forum) but that's hardly their fault.
If you want the great visuals, don't play on a low res laptop screen... You cant expect all the bells and whistles of a PC game unless you are willing to build or buy a good rig (along with monitor) to run it on.
Again, I mean that in the nicest possible way my friend.
Constructive suggestion here, is there any way to output your gaming laptop (by gaming I'm assuming you mean you think it's powerful enough to run supersampling etc.) to a monitor? That might solve your problem at least.
My (or, to some extent, everybody's) problem is the fact that ED's antialias is just terribad compared to pretty much any other game. On non-ultraHD screens it's just more apparent
I think a lot of the limitations and issues are probably a result of API allowances.
DX does quite a fair bit, I can even honestly say it does some of it rather well. But then there are parts it doesn't do so well, and shader-based AA is one of the things it doesn't do well at all.
I spend some (rather limited) free time on a Source Code Project for space combat game myself, our engine though is (now) entirely OpenGL based. And while that has its own difficulties (one of which being: No actual options for AA in-game -except- FXAA via a Post Processing Shader) it has the bonus that any desired level of AA can be set in the video card control panel and take effect. Though, if you also want it to apply while Post Processing is on, that is another matter entirely, as the two don't tend to co-operate well at all, but for nVidia users at the minimum, it is entirely possible to have both by forcing SGSSAA in combination with setting the FXAA bit in the CP to "on" and turning off (or not choosing to enable) the games shader based FXAA.
Prior to Post Processing and FXAA (and these were fairly recent developments, but this is based on hobbiests free-time coding on top of an engine with code in some places that was originally written in 1994), driver based enforcement was VERY easy for anybody to do (and is still possible, but with more work) entirely outside of the game itself.
As a further note: We have a branched version where we are working on Deferred Rendering, which still has Post Processing (and shadows and a lot more versatility to the lighting) and the same application (outlined above) for forcing external AA works just as well as it does on the "Release" version.
In short, I don't think that this is really entirely so much the fault of the Cobra engine specifically, as I think it is a result of the Cobra engine specifically being hamstrung by the dictates of going with DX11 (though I was pretty sure that Dangerous was able to run in DX10 as I played during beta initially on an 8800 GT). I'm actually rather surprised, given that a Mac version is intended, that FD went with pursuing utilizing the DX API set instead of the OpenGL method (though the can of worms there is requiring specific Forward Contexts based on OpenGL Version being targeted) as it would also open up a greater potential for a Linux variant rather/more easily from there.
DX does quite a fair bit, I can even honestly say it does some of it rather well. But then there are parts it doesn't do so well, and shader-based AA is one of the things it doesn't do well at all.
I spend some (rather limited) free time on a Source Code Project for space combat game myself, our engine though is (now) entirely OpenGL based. And while that has its own difficulties (one of which being: No actual options for AA in-game -except- FXAA via a Post Processing Shader) it has the bonus that any desired level of AA can be set in the video card control panel and take effect. Though, if you also want it to apply while Post Processing is on, that is another matter entirely, as the two don't tend to co-operate well at all, but for nVidia users at the minimum, it is entirely possible to have both by forcing SGSSAA in combination with setting the FXAA bit in the CP to "on" and turning off (or not choosing to enable) the games shader based FXAA.
Prior to Post Processing and FXAA (and these were fairly recent developments, but this is based on hobbiests free-time coding on top of an engine with code in some places that was originally written in 1994), driver based enforcement was VERY easy for anybody to do (and is still possible, but with more work) entirely outside of the game itself.
As a further note: We have a branched version where we are working on Deferred Rendering, which still has Post Processing (and shadows and a lot more versatility to the lighting) and the same application (outlined above) for forcing external AA works just as well as it does on the "Release" version.
In short, I don't think that this is really entirely so much the fault of the Cobra engine specifically, as I think it is a result of the Cobra engine specifically being hamstrung by the dictates of going with DX11 (though I was pretty sure that Dangerous was able to run in DX10 as I played during beta initially on an 8800 GT). I'm actually rather surprised, given that a Mac version is intended, that FD went with pursuing utilizing the DX API set instead of the OpenGL method (though the can of worms there is requiring specific Forward Contexts based on OpenGL Version being targeted) as it would also open up a greater potential for a Linux variant rather/more easily from there.