Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
So there are certain high contrast conditions or when post process effects are being blended in which Aliasing can't be resolved. RIm lighting and edge lighting being prime examples which will create sharp bright contrasts with no smoothing.
This can't be fixed until the game is upgraded to the latest versions of Unity which have been using deffered rendering for several years now where TAA would be possible and standard by default.
So... That means I'll just stare at 15 fps pixelated images for a while... Oh well, I guess I should just wait.
Chill, bro, I know that, I'm asking just to be sure that it's not a problem with my gpu or anything.
Yea, Early Access won't change the kind of renderer they use USUALLY. In this case on one of their dev posts they actually did suggest that an upgrade to the latest version of Unity's deferred renderer may happen but by no means is that a 100% for sure promise.
99% of the time stuff like that DOESN'T change throughout the Early Access period. This is why Early Access preys on people who don't know that much about game development.... If KSP 2 ever gets TAA it would be a unique example of an EA game doing so.
KSP1 got Unity version updates well after full release. This game is not really the prime example of EA games, is it, it seems mostly speculation at this point? All of that aside, it hardly seems to be a priority. It's entirely possible this will be available in a year or three.
It's not the same as your standard Game Engine update though, Unity supports both Forward and Deferred Renderers and this game uses a Forward Renderer version, KSP 1 used a Forward Renderred version for all of it's version history.
Changing this halfway though is more significant than a minor engine upgrade which Unity will basically do for you, assets and certain rendering features (all your lighting and materials) will have to be reconsidered when this change happens, if it happens.
PS: That's not to say it won't happen, although I would certainly assert that if the devs hadn't noted their intention to do so in their post related to Terrain Rendering. The purpose of my Original comment was to push back against the person who simply declared the game as being "unfinished", this isn't an unfinished thing it's the render pipeline of the Engine which you typically choose FROM DAY ONE and it doesn't change later 99% of the time. It wouldn't be reasonable to assume it WOULD if we hadn't have had that dev post and now you're in the territory of hoping they do something that iirc isn't on any kind of road map list..
Just for fun here is a list of games that use forward rendering
That being said, KSP2 has better graphics in its current unfinished state that KSP1 does.
https://www.youtube.com/watch?v=JTQWJEd3m6o
Agreed, I've done both before.
My interpretation of the statement is that it's a "nice to have". I don't think it's likely either given what else they need to take care of first. On the other hand it could have been in the pipe all along and what we got is the transitional version. What do we really know? Would they even put something technical like that on a roadmap?
I find this comment to be odd because it looks like you know just enough "to be dangerous" as they say.
Like, maybe you did a quick google search and made up your own conclusions based on that but you clearly don't fully understand the difference between Forward and deffered rendering or you'd know the principal difference which is MSAA and modern Post-Process Anti-Aliasing techniques such as TAA - (which rely on Post-Process buffers not supported by a forward renderer.)
^
The fact that KSP 2 uses Forward Rendering, limiting it to MSAA Anti-Aliasing leaves it without any technique to handle Temporal Aliasing which is the sole reason why the game has the Aliasing that OP complained about.
It's the literal reason.
Furthermore on lighting, - Yea the way it changes how lighting is calculated affects the per pixel shader of the MATERIAL that's being rendered, the order is different and it results in significantly more redundant rendering. For example the Material, textures and all other instructions are rendered in full FOR EACH LIGHT separately..... This is why the Terrain shader is so expensive in KSP 2 but it's not just light sources... It's other affects that fetch that data too.
^
In other words because we only see materials that are lit, how lighting works in a renderer directly affects the rest of the render pipeline and that doesn't stop at Material instruction cost, post-process affects are limited too because you lack a wide range of Temporal buffers that modern games use for advanced post-process affects before the final lighting pass is presented.
(I just noticed you said it literally doesn't affect how textures are displayed, you're 100% incorrect for the reasons listed above)
- By affecting when a Material is calculated and when the final lighting pass is done it directly affects material cost.
- By not having support for various G-buffers that most modern games use for advanced effects you directly restrict how that object can be visually presented
Per example Temporal Shimmering, which a Forward Renderer literally can't address and that's purely a texture bound artifact.
Back to Anti-Aliasing and your game list, you need a source for that list because I don't believe it. Notably some of the games you listed have rendering features that aren't supported by Forward Rendering such as TAA and DLSS.
There is a method known has Hybrid-Forward Rendering like the modern Doom games use, but these are forward renderers where the devs have manually built deferred rendering pipelines on top of and then they blend the results, it's possible to do but it is rarely done because that's a highly technical task, at that point you're not talking about your basic forward renderer but something that in all rights should be considered a novel solution by those individual studios which include genuine deferred rendering features.
PS: Technically the perfect solution would be a hybrid approach that can leverage the benefits of both systems because that would be the most performant if done properly, but you need Graphics engineers with the kind of skills to make their own rendering engines from scratch to pull it off and it will still come with unique restrictions requiring novel solutions. Doom indeed runs and looks very good but KSP 2 clearly hasn't wen't that route. I can tell it uses Forward Rendering just by looking at it for 2 seconds, the notable Temporal Aliasing is the tell all.
^
Forward Rendering remains popular for VR games because although we may complain about Temporal Aliasing here, in VR games they would complain about the blur TAA/DLSS would add to motion and in that case MSAA offers an extremely performant Anti-Aliasing with a crisp imagine each and every frame, it just can't address all types of Aliasing.
So it doesn't track to say that such pixelation is just a natural consequence of the basic rendering technology.