That's because TXAA is part of Nvidia Gameworks while the term TAA is just a generic term.
TEMPORAL ANTI-ALIASING like this would be awesome in Elite Dangerous.
- Thread starter Kapow
- Start date
That's because TXAA is part of Nvidia Gameworks while the term TAA is just a generic term.
That's because TXAA is part of Nvidia Gameworks while the term TAA is just a generic term.
I would imagine Nvidia WANT it to be a general solution. After all, AA has been something of a technological bugbear for many years. Cripes, since 1960 when you think about it (apart from on Vector displays...).
I would imagine the Nvidia shader/pipe team will be feverishly working on getting this whole pipe buffed, with documentation out there to help game engine developers implement it.
I was thinking, for VR, this could be even more efficient. Because, not only can use re-use samples from previous frames. But you can also SHARE these samples across eyes. Each eye renders a separate, though similar pair of views. So an extension of TAA, is to combine these sample streams from each eye (each eye, rendering, ideally at 90fps).
I think Nvidia already have a lot of this in the bag. As the Pascal drivers allow for sharing of samples between eyes. Nvidia did this, so that rendering two view of the same basic scene, becomes basically free.
I guess, if we can get TAA, combined with two eye views, that visuals in VR will actually take something of a leap forward.
Was my guess, that this method is not especially difficult to implement. Especially when they drop DX10 and 32-bit support to make the rendering code leaner. Now, where do I go and nag so it gets on Frontier's list again?
Agree. Nvidia Gameworks is a fantastic set of features, on paper that is. Implementation of the various features has been proved to be disastrous for a few games ( Arkham Knight anyone?). It's also been a target of a lot of conspiracies, saying Gameworks deliberately decreases performance on AMD cards.
Gameworks is a selling point, and no doubt Nvidia tries to make more and more studios to use it. However, when it works, it really does wonders for the graphics.
I'm very intrigued by the new Pascal technologies like simultaneous multiprojection and single-pass stereo. But it is also important to remember that this technology is partly buried inside the Pascal architecture itself which means Maxwell users or lower can't use the new exciting tech.
On the aliasing topic...
If we keep on using our regular pixel displays, aliasing will always be present. When we can ditch this old technology, and use something that *can* draw diagonal lines, we don't even need anti aliasing because there wouldn't be any jaggies at all to counteract.
Well, its actually not trivial to implement. Each object in your scene, needs to write to a buffer, to tell the next frame, where to look for the same geo in its shading cache.
Having said that, the chaps and chapettes at Frontier are clever cats. Im sure its not beyond them. Recently they optimized the code, so the game in general ran MUCH faster. With that in the bag, it would be great if they spent a point release cycle or two implementing support for TAA.
It WOULD make such a massive improvement to the look / visual quality of the game.
Moral of the day.
Do not do serious projects in casual (Unity) or even homebrewed game engines. It wastes time of devs, money and energy and in the end, you will end with subpar.
Doing it yourself is better, in that you have 100% control over the engine and its capabilities. Down side is, you have to do everything. I guess Frontier have gone they way they have, for a reason.
Maybe because Mr Braben has always, historically, written his own engine, and tend to think that way. Who knows.
Anyway, they ARE using / developing Cobra. So implementing TAA is within their control.
It was wrong and ED is all the poorer for it.
Problem is not doing everything, problem is doing everything in a top tier fashion. Impossible for small uk company. Cryo, Unreal or Unigine have large dedicated teams who live and breathe gpu stuff. FDev? Judging from ED progress.. 9 to 5 attitude.
Problem is not doing everything, problem is doing everything in a top tier fashion. Impossible for small uk company. Cryo, Unreal or Unigine have large dedicated teams who live and breathe gpu stuff. FDev? Judging from ED progress.. 9 to 5 attitude.
Last edited:
To be honest running in "your own engine" is something rather common for Space games (especially with multiplayer features) as Double Precision is something rather desired and neither Unreal, CryEngine or Unity offer such features, so you end up relying on Level Streaming with point of origin locked to the player/avatar which is more complex issue for Multiplayer. While I believe I have read somewhere that ED is double precision it does feel rather like a level streaming game due to the large amount of "loading" screens - dropping from hyper space, dropping to stations ect. But it could easily be just instancing loading as I've had some experiences which seemed seamless (very very very rare experiences). So I understand the desire to use their own bespoke engine for the game as it makes things a bit easier for some aspects of the development, but on the other hand I can not understand that the AA has been issue for over 2 years now. This issue is much more pronounced in VR and if I compare the experience I can achieve with ValveLab setup in Unity on my Vive it shows how much is left to desire in Vive EXP in ED. It makes ED look like an outdated tech demo with huge issues and the main solution FD persists on is Super Sampling which is a FPS killer (more so in VR). VR needs good AA solution - Valve bangs on about it, Unreal beats it over the devs heads and so does CryEngine, so not having any modern AA in a (supposedly) VR game is tragic sadly...
Comparing VR lab AA with ED is a bit silly. ED throws around significantly more geometry, effects, lighting and textures. VR lab is design from the ground up to minimise aliasing and to afford super sampling at 90Hz stereo. You need a beast of a card to do that with ED because it's doing so much more.
Any deferred renderer like ED's required high cost SSAA until pretty much this year. Games that could afford it were essentially PS3/X360 ports running on better hardware.
Games that have been develop from the ground up to use evolved TAA have only just started appearing.
We've no idea how much shader rework building it into ED would take. We've also no idea how well elements like space dust and orbital lines would be dealt without serious effort to avoid artifacts.
Any deferred renderer like ED's required high cost SSAA until pretty much this year. Games that could afford it were essentially PS3/X360 ports running on better hardware.
Games that have been develop from the ground up to use evolved TAA have only just started appearing.
We've no idea how much shader rework building it into ED would take. We've also no idea how well elements like space dust and orbital lines would be dealt without serious effort to avoid artifacts.
Last edited:
I find that TAA has been around for long enough for any Engine to adopt and I mean that with no disrespect. Unreal has TAA since 2013 and even the old Cry Engine 3 (5 years ago or so) had better AA (not TAA though ) then anything available to us in the current version of ED as Cobra AA solution is supersampling and then only the most basic Post Effect AA available. Basically the Devs haven't spent any time on it and considering the complexity of the Geometry and the Nature of Space Games it should have been one of the priorities.
Yep the VRlab is an extreme example and I as many others understand that it is not something we are likely to see in ED (I've been working in Unreal and Unity for years to undestand the complexity of the subject), but not implementing modern AA is also shambles as it leaves anybody wanting to play in VR to need GTX 1080 to just get mediocre experience while with good optimization and proper AA we could enjoy it well on 980 or 980ti and get really amazing experience with 1080 and therefor it does leave a lot to be desired until proper AA is introduced, more so in VR then in standard 2D...
Last edited:
There is a difference between a technique being around and widely used in projects. There also a different between using it in a game released in 2016 vs adding it back into a game started in 2013, where there are many competing programmer and artist tasks and more associated risk of breaking something.
I certainly would like the devs to be looking at it too, or I wouldn't have restarted this thread. I disagree with the lazy devs slant to your post though.
I certainly would like the devs to be looking at it too, or I wouldn't have restarted this thread. I disagree with the lazy devs slant to your post though.
There is a difference between a technique being around and widely used in projects. There also a different between using it in a game released in 2016 vs adding it back into a game started in 2013, where there are many competing programmer and artist tasks and more associated risk of breaking something.
I certainly would like the devs to be looking at it too, or I wouldn't have restarted this thread. I disagree with the lazy devs slant to your post though.
Not meant to come across as Lazy per say
more as easiest way through an issue which is something Frontier does a lot in large chunks of the game. Their game has a pattern of solutions that are of the lowest resistance. In other words - there isn't all that much inventiveness from them, path of lowest resistance and lowest common denominator is often chosen (Exemplary is the recent Passanger Lounge which is simply a cargo reskin and has little value/enrichment to gameplay and ED is full of such fillers/time dumps). I'm not saying that they are lazy. It can be due to the size of the team and funding or simply due to the complexities of their pipeline (yes this can be read as messy programming) which causes them more headaches then needed. A lot of the bugs often reported on each version release are repeat offenders and some bugs (10cr paint) has been there since the dawn of time . So not lazy per say, but more in terms of messy or underfunded for the size of the project.TAA is engine specific so the actual outcome of that anti aliasing depends entirely on how the developers do. This is why some games and engines with TAA looks different.
Unreal Engine 4 has a very effective TAA but it makes everything extremely soft/blurred. ED is indeed a unique case with things like orbital lines and complex geometry.
Unreal Engine 4 has a very effective TAA but it makes everything extremely soft/blurred. ED is indeed a unique case with things like orbital lines and complex geometry.
Try using SS=2.0. It does a noticeably better job than 1.5. Lately, I've been running 2560x1440 at ss=2.0. I get a tolerable frame rate (~30-60 fps) on my GTX 980 Ti. The crawling lines are still present, but the artifacts are reduced. This seems to be the best compromise for my system. It's a shame that I can't use 4k, which is the native res of my monitor, but it's too slow with SS=2 and too annoying to run with SS=1.0 or 1.5.
Last edited:
760 would struggle with 2.0 SS, it is unplayable with my 780Ti with 2.0 if I have anything set at a decent quality setting.
Still when I tested 2.0 on my card, it looked a little better but jaggies were still pretty bad @1080p.
I wish I could un-see it haha! Bugs the hell out of me now! All these beautiful graphics and all I can focus on is the flashing, stroby lines as I move my head around
Is there any generic 3rd party TAA injectors that can be used for ED?
Still when I tested 2.0 on my card, it looked a little better but jaggies were still pretty bad @1080p.
I wish I could un-see it haha! Bugs the hell out of me now! All these beautiful graphics and all I can focus on is the flashing, stroby lines as I move my head around
Is there any generic 3rd party TAA injectors that can be used for ED?
Is there anyway to get this into the eyes of FDEV? has anyone emailed them about this AA solution?