ronson49

I just heard of KSP 2. Are they officially using Unity?

Recommended Posts

Just now, mcwaffles2003 said:

Do you mean to say they are considering finding a way to make this multi-threaded? I thought that was out of the question for reasons of difficulty

No, not threads, cores. 

Multi-core and multi-thread are two different things. 

Multi-core means that the game runs on more than one core. IIRC, KSP 1 still runs on a single core or two cores, at most, of your CPU, that's one of the major performance issues. You could have AMD's 32 core CPU and the game would still only use 1 or 2 cores. 

Multi-thread means basically splitting a core in 2, so 4 cores, 8 threads. 

Single-core performance is sometimes better than multi-core performance. That's what they're trying to decide.
Whether 1 core gaming is better than 2, 4, 6, etc cores. 

Share this post


Link to post
Share on other sites
1 hour ago, GoldForest said:

No, not threads, cores. 

Multi-core and multi-thread are two different things. 

Multi-core means that the game runs on more than one core. IIRC, KSP 1 still runs on a single core or two cores, at most, of your CPU, that's one of the major performance issues. You could have AMD's 32 core CPU and the game would still only use 1 or 2 cores. 

Multi-thread means basically splitting a core in 2, so 4 cores, 8 threads. 

Single-core performance is sometimes better than multi-core performance. That's what they're trying to decide.
Whether 1 core gaming is better than 2, 4, 6, etc cores. 

Programs normally aren't aware of CPU cores; there's ways to get the OS to return this information but normally it's far easier to define separate threads and then let the OS handle them in the background. So "multithreaded" in the programming sphere can be used to describe " a program that uses multiple cores" 

 

Share this post


Link to post
Share on other sites
7 hours ago, Drakenred65@Gmail.com said:

Creation engine is behind Skyrim and fallout 76.

The CE takes a lot of backslash because of its graphics when Interaction wise it's one of the most advanced.

Oblivion had single pickable and readable books in bookcases when the most graphically advanced games of the time were using static models or even 2d textures with the bookshelf drawn on, Skyrim has all the props to be physic based instead of being glued in place like in most other games and F76 managed to get the CE working in multiplayer on the same hardware that runs F4 which is a miracle on its own.

When you hear someone blaming the game engine you can always be sure they don't know what they're talking about, especially with Unity and the Creation Engine.

Share this post


Link to post
Share on other sites
3 minutes ago, Incarnation of Chaos said:

Programs normally aren't aware of CPU cores; there's ways to get the OS to return this information but normally it's far easier to define separate threads and then let the OS handle them in the background. So "multithreaded" in the programming sphere can be used to describe " a program that uses multiple cores" 

 

That's kind of misleading. 

Share this post


Link to post
Share on other sites
Just now, GoldForest said:

That's kind of misleading. 

Not really since given the context it makes sense; multithreaded just has different meanings depending on context. 

What you described is accurate when talking about CPU hardware, and it's actually possible to make a program spawn multiple threads on the same core. But when we're talking about "multithreading a program" we're always talking about making it use multiple physical cores.

Share this post


Link to post
Share on other sites
19 hours ago, linuxgurugamer said:

First, you are correct that the current performance is not optimized, by a lot.  That's due to the inherent design of the current KSP

Second, multi-threading done correctly is extremely difficult to do.  I don't know the details of how the Intel chips work, but there are several ways around bottle necks.  One is to allocate chunks of memory to cpu A for it's work, another chunk to B, etc.  These chunks would need to be an exact size which matches what the memory manager can handle.  Best thing to say is that the new developers are optimizing KSP in many different ways, and we won't know exactly what or how until the release.

 

Well not matter how optimized it will be I'm doing a cpu upgrade for its release IF the game is good. My 4770k is still more than enough most likely but better single core performance will be nice. I've not looked into current releases or upcoming releases yet but I want something with 4ghz with a 5ghz boost. That's probably about 50-70% more single core performance. I often considered doing an upgrade for ksp1 but wasn't confident in the performance gain. 

Share this post


Link to post
Share on other sites
4 minutes ago, dave1904 said:

Well not matter how optimized it will be I'm doing a cpu upgrade for its release IF the game is good. My 4770k is still more than enough most likely but better single core performance will be nice. I've not looked into current releases or upcoming releases yet but I want something with 4ghz with a 5ghz boost. That's probably about 50-70% more single core performance. I often considered doing an upgrade for ksp1 but wasn't confident in the performance gain. 

it would definately improve performance on KSP 1 as i know its single threaded, so it all comes  down to clock speed. I believe greater cache would also help a lot as that leave less time per frame waiting for you CPU to grab data out of RAM which is much slower. 

I'm a bit sad my 2700x only uses 1 thread when it has 16 available, if they go and make the game multi-threaded that would be awesome but even just having it GPU accelerated would be great since I have 11GB of VRAM

Share this post


Link to post
Share on other sites
3 hours ago, GoldForest said:

No, not threads, cores. 

Multi-core and multi-thread are two different things. 

Multi-core means that the game runs on more than one core. IIRC, KSP 1 still runs on a single core or two cores, at most, of your CPU, that's one of the major performance issues. You could have AMD's 32 core CPU and the game would still only use 1 or 2 cores. 

Multi-thread means basically splitting a core in 2, so 4 cores, 8 threads. 

Single-core performance is sometimes better than multi-core performance. That's what they're trying to decide.
Whether 1 core gaming is better than 2, 4, 6, etc cores. 

I doubt they will. Some people might want to upgrade to something more than a 2.3 duo core instead of complaining. A bad cpu is a bad cpu. Doesn't mean it cannot be optimized but some people expect games to run goood on really bad hardware. 

Share this post


Link to post
Share on other sites
18 minutes ago, dave1904 said:

I doubt they will. Some people might want to upgrade to something more than a 2.3 duo core instead of complaining. A bad cpu is a bad cpu. Doesn't mean it cannot be optimized but some people expect games to run goood on really bad hardware. 

I'm sorry, but your post makes no sense to me and doesn't seem to respond to anything in my comment. 

Share this post


Link to post
Share on other sites

I've been trying to resist stepping but... fail. This multi-thread/multi-core discussion is just so wonderfully on the cusp of almost right with just the right amount of misconceptions and half-truths mixed in that I just have to set the record straight.

First, the concepts: 

core is a physical or virtual device capable of executing instructions

thread is a sequence of instructions (=a program) executed by a core in a series

multicore is a computing device that has more than one core (typical CPUs nowadays have 4-8 cores; typical GPUs have thousands -- the GTX 1080 for example has 2560 cores)

multithreading is writing a program as more than one thread, with each thread executed in parallel

pre-emptive multitasking is what the OS does to cycle cores through threads, attempting to keep all of them moving and none of them blocking any other threads

First off, we've been writing multithreaded programs since way before multicore CPUs became common. So while it's true that a single-threaded program can only run on one core, it's not true that multithreading means making a program run on multiple cores. It might or it might not but that's more of a side effect. There are usually more threads than cores anyway, so the OS will be multitasking between them anyway, whether there's one core or 8.

So it is strictly not true that "multithreading a program" means "making it run on more than one core." 

Second, not every problem lends itself to multithreading. Multithreading makes a lot of sense if the following conditions are met:

  • Each thread is independent of any other thread
  • Thread synchronisation is needed rarely or not at all, and if it is needed, it can be done simply with little computational overhead
  • Each thread operates on its own data

A typical terrific application for multithreading is graphics rendering. You can basically chop up the screen into 2560 chunks and render each of them independently into a buffer, and then 30, 60, or 120 or however many times a second you want, read the buffer from each pipeline, assemble it into a full screen, and display the result. 

A really terrible application for multithreading is rigid-body physics where every part can -- in theory or in practice -- act upon every other part. You have to compute the state of the entire system in one thread because subsequent computations depend on preceding ones. The only way to multithread that is if you can identify chunks of the scene that aren't interacting with each other, and shunt those off to their own threads. So for example each craft in a physics scene can have its own thread. However, if the crafts collide, then suddenly they're interacting again, and one of the threads must take over, or you must spawn a new one -- and that carries performance overhead too, which you will likely notice as a stutter when craft approach each other, collide, dock, or undock.

Third, even in the best case, multithreading carries overhead costs. In the GPU rendering situation for example we have additional steps: writing the chunk of image into a buffer, then reading it from the buffer and assembling it into an image: all this requires memory and core time. (IRL there's more there too I'm sure, related to timing, making it possible for pipelines to skip frames if they're lagging, and so on and so forth.) If any of the above assumptions doesn't hold -- and they almost never 100% hold! -- there's going to be more overhead. And if you find that you need to do a lot of thread syncing, write- or read-locking data, watching out for situations where threads need to be merged, spawning or killing threads, or other similar stuff, you might find that anything you gained from multithreading was lost in that overhead.

Fourth, multithreading can get complicated fast. That overhead I mentioned above doesn't just slow things down and consume resources (memory, f.ex.) -- it can also get seriously complicated to write. For example if you're putting each craft in its own physics thread, you need to write the code that detects when they collide, which means you need to have some way to make sure each thread is in sync with system time; then you need to write the code that merges the two threads to compute the interaction. This stuff will cause entire categories of often really hard-to-reproduce, hard-to-find, and hard-to-squash bugs to emerge. A race condition, for example, is when two threads both try to operate on the same data and lock each other out, which causes the whole system to grind to a halt -- and they're notoriously difficult to pre-empt, detect, and fix. 

Summa summarum, multithreading is hard, it's only suitable for specific types of problems, it doesn't even always help, and it's only tangentially related to multicore CPUs. Heavy-duty planetary-scale server software has been gradually moving away from multithreaded architectures for these reasons -- even though on the face of it a server which serves thousands of clients at the same time sounds like a perfect application for multithreading. Quite often a well-written efficient single-thread solution ends up faster, more robust, and less buggy than a multithreaded one. 

Edited by Brikoleur

Share this post


Link to post
Share on other sites

 

19 minutes ago, Brikoleur said:

So while it's true that a single-threaded program can only run on one core, it's not true that multithreading means making a program run on multiple cores

This is hyperthreading, correct?

21 minutes ago, Brikoleur said:

A really terrible application for multithreading is rigid-body physics where every part can -- in theory or in practice -- act upon every other part. You have to compute the state of the entire system in one thread because subsequent computations depend on preceding ones. The only way to multithread that is if you can identify chunks of the scene that aren't interacting with each other, and shunt those off to their own threads. So for example each craft in a physics scene can have its own thread. However, if the crafts collide, then suddenly they're interacting again, and one of the threads must take over, or you must spawn a new one -- and that carries performance overhead too, which you will likely notice as a stutter when craft approach each other, collide, dock, or undock.

So its easy to multithread multiple ships if it werent for collisions, correct? Since they can be considered different chunks. Could not a thread be made for detecting said collisions and compiling both chunks into one upon interaction then treat them, for the time being of their interaction, as one chunk in one thread then separated again upon ending the interaction? And if the case is so could a single ship be made into chunks and a thread be responsible for merging the chunks or would you have caching problems with that and interruptions occurring over sharing memory between caches?

If rigid-body physics is truly only optimizable for single threaded applications could that be predetermined and have cores that arent being utilized donate their caches to the core being utilized to increase cache size and reduce latency, therefore increasing performance? Or is this prevented at the level of hardware, ie AMD bulldozer with Clustered Multi-threading vs Intel Hyper-threading back in the day?

Share this post


Link to post
Share on other sites

About multithreading in Unity and .NET:

If you use the default Task/Thread from .NET, normaly the OS or the Runtime manage on which core a Thread run.

Starting Thread has some overhead, newer .NET versions has the Task (in KSP 1 < 1.8 not available), who use a threadpool and with async/await you can easier write multithreading code. But switchiing context (task to mainthread) and Garbage collection make this approach not suitable for perfomance criticial game code.

Unity has with the C# job system his own multithreading solution, specially designed for games. Unity starts one Backgroundthread on each logical core (1 core reserved for the maintread) and schedule jobs.

And with the Burst compiler they compile the jobs with LLVM/Clang to optimized machine code.

Share this post


Link to post
Share on other sites
20 minutes ago, mcwaffles2003 said:

This is hyperthreading, correct?

Nope, hyperthreading is Intel's trademark term for making a single physical core appear to the operating system as multiple virtual cores. (This helps in some specific situations but why would be a long tangent; it's not really something anyone who's not intimately involved with the technology should care about IMO.)

20 minutes ago, mcwaffles2003 said:

So its easy to multithread multiple ships if it werent for collisions, correct? Since they can be considered different chunks. Could not a thread be made for detecting said collisions and compiling both chunks into one upon interaction then treat them, for the time being of their interaction, as one chunk in one thread then separated again upon ending the interaction? And if the case is so could a single ship be made into chunks and a thread be responsible for merging the chunks or would you have caching problems with that and interruptions occurring over sharing memory between caches?

Certainly, but as I pointed out, that would be complicated and introduce overhead. (My intuition is that yes, in fact it would be worth doing if indeed KSP doesn't do this already.)

20 minutes ago, mcwaffles2003 said:

If rigid-body physics is truly only optimizable for single threaded applications could that be predetermined and have cores that arent being utilized donate their caches to the core being utilized to increase cache size and reduce latency, therefore increasing performance? Or is this prevented at the level of hardware, ie AMD bulldozer with Clustered Multi-threading vs Intel Hyper-threading back in the day?

Nope, that won't work, it is prevented by the hardware. CPU caches are physically wired to the core on the same bit of silicon; that's the whole point as it makes it possible for them to have orders of magnitude lower latency than RAM for example. So you can't have a core donating its cache to another core even on the same chip, the wires aren't there. (Caching is another incredibly complicated ball of yarn by the way, it's another thing IMO that nobody should care about unless they're intimately involved with the technology, in which case they need to care about it very very much indeed.)

---> again, I'm not a game programmer so I'm just throwing stuff at the wall here, but ...

... my intuition as a programmer tout court is that the best way to optimise physics in KSP is to find ways to reduce and ideally cap the number of computations needed. Some kind of level of detail (LOD) system in other words. So if you've determined that the physics engine handles 255 parts no problemo but after that performance starts degrading fast, you add an algorithm that automatically welds anything bigger than that into 255 chunks, each of which is treated as a single part for physics computations. For interactions between craft, give them an invisible collision box that triggers a re-weld so that the total part count inside the collision box is still below 255. These recomputations could be shunted off to separate threads, only switching to the new model when it's ready so if done well it wouldn't even be perceptible to the user. Moreover, LOD systems are really well-worn territory in graphics rendering and I'm pretty sure similar solutions could be applied to physics.

So basically if you make the interstellar ship It's The Little Things That Matter, and it has 2550 parts, KSP would secretly treat it as 255 parts. It would effectively scale as high as you'd like; only effect would be that loading craft into a scene would take a bit longer as the welds are computed. And of course in case of RUD the craft would come apart at those seams making for a slightly different-looking explosion; the overall effect on gameplay would be as good as imperceptible however.

(In fact I seem to recall that Star Theory mentioned physics LOD at some point, and they have been woofing that KSP2 scales to 5000-part plus craft no problem... so putting 1 and 1 together it does seem to me that they have something like this solution in place.)

Edited by Brikoleur

Share this post


Link to post
Share on other sites
Spoiler
1 hour ago, Brikoleur said:

I've been trying to resist stepping but... fail. This multi-thread/multi-core discussion is just so wonderfully on the cusp of almost right with just the right amount of misconceptions and half-truths mixed in that I just have to set the record straight.

First, the concepts: 

core is a physical or virtual device capable of executing instructions

thread is a sequence of instructions (=a program) executed by a core in a series

multicore is a computing device that has more than one core (typical CPUs nowadays have 4-8 cores; typical GPUs have thousands -- the GTX 1080 for example has 2560 cores)

multithreading is writing a program as more than one thread, with each thread executed in parallel

pre-emptive multitasking is what the OS does to cycle cores through threads, attempting to keep all of them moving and none of them blocking any other threads

First off, we've been writing multithreaded programs since way before multicore CPUs became common. So while it's true that a single-threaded program can only run on one core, it's not true that multithreading means making a program run on multiple cores. It might or it might not but that's more of a side effect. There are usually more threads than cores anyway, so the OS will be multitasking between them anyway, whether there's one core or 8.

So it is strictly not true that "multithreading a program" means "making it run on more than one core." 

Second, not every problem lends itself to multithreading. Multithreading makes a lot of sense if the following conditions are met:

  • Each thread is independent of any other thread
  • Thread synchronisation is needed rarely or not at all, and if it is needed, it can be done simply with little computational overhead
  • Each thread operates on its own data

A typical terrific application for multithreading is graphics rendering. You can basically chop up the screen into 2560 chunks and render each of them independently into a buffer, and then 30, 60, or 120 or however many times a second you want, read the buffer from each pipeline, assemble it into a full screen, and display the result. 

A really terrible application for multithreading is rigid-body physics where every part can -- in theory or in practice -- act upon every other part. You have to compute the state of the entire system in one thread because subsequent computations depend on preceding ones. The only way to multithread that is if you can identify chunks of the scene that aren't interacting with each other, and shunt those off to their own threads. So for example each craft in a physics scene can have its own thread. However, if the crafts collide, then suddenly they're interacting again, and one of the threads must take over, or you must spawn a new one -- and that carries performance overhead too, which you will likely notice as a stutter when craft approach each other, collide, dock, or undock.

Third, even in the best case, multithreading carries overhead costs. In the GPU rendering situation for example we have additional steps: writing the chunk of image into a buffer, then reading it from the buffer and assembling it into an image: all this requires memory and core time. (IRL there's more there too I'm sure, related to timing, making it possible for pipelines to skip frames if they're lagging, and so on and so forth.) If any of the above assumptions doesn't hold -- and they almost never 100% hold! -- there's going to be more overhead. And if you find that you need to do a lot of thread syncing, write- or read-locking data, watching out for situations where threads need to be merged, spawning or killing threads, or other similar stuff, you might find that anything you gained from multithreading was lost in that overhead.

Fourth, multithreading can get complicated fast. That overhead I mentioned above doesn't just slow things down and consume resources (memory, f.ex.) -- it can also get seriously complicated to write. For example if you're putting each craft in its own physics thread, you need to write the code that detects when they collide, which means you need to have some way to make sure each thread is in sync with system time; then you need to write the code that merges the two threads to compute the interaction. This stuff will cause entire categories of often really hard-to-reproduce, hard-to-find, and hard-to-squash bugs to emerge. A race condition, for example, is when two threads both try to operate on the same data and lock each other out, which causes the whole system to grind to a halt -- and they're notoriously difficult to pre-empt, detect, and fix. 

Summa summarum, multithreading is hard, it's only suitable for specific types of problems, it doesn't even always help, and it's only tangentially related to multicore CPUs. Heavy-duty planetary-scale server software has been gradually moving away from multithreaded architectures for these reasons -- even though on the face of it a server which serves thousands of clients at the same time sounds like a perfect application for multithreading. Quite often a well-written efficient single-thread solution ends up faster, more robust, and less buggy than a multithreaded one. 

 

This is one of the absolute best explanations of WHY the rigid-body physics model KSP isn't parallelizable iv'e seen in plain English; thank you even though i doubt it was your intent xD 

As for the difference between multithreaded software and multicore software i must also acknowledge that @GoldForest was correct and thank @Brikoleur for clearing up the waters and sharing the rest of this information.  

 

 

Share this post


Link to post
Share on other sites
2 hours ago, mcwaffles2003 said:

it would definately improve performance on KSP 1 as i know its single threaded, so it all comes  down to clock speed. I believe greater cache would also help a lot as that leave less time per frame waiting for you CPU to grab data out of RAM which is much slower. 

I'm a bit sad my 2700x only uses 1 thread when it has 16 available, if they go and make the game multi-threaded that would be awesome but even just having it GPU accelerated would be great since I have 11GB of VRAM

Anything more than 4 cores hyperthreaded is overkill. Why Intel has already decided to go 6 cores for the gaming cpus is beyond me. Do not expect better multithreading for ksp2. I'm 100% sure physics will be singlethreaded. If not I hope someone from the future can reply and tell me how wrong I hopefully am. 

Share this post


Link to post
Share on other sites
40 minutes ago, dave1904 said:

Anything more than 4 cores hyperthreaded is overkill. Why Intel has already decided to go 6 cores for the gaming cpus is beyond me. Do not expect better multithreading for ksp2. I'm 100% sure physics will be singlethreaded. If not I hope someone from the future can reply and tell me how wrong I hopefully am. 

Two reasons why Intel went with more cores: First off, your computer is doing a lot more than just running the program you're interacting with.  Having additional cores for background processes, OS process, etc. makes sense.  Secondly - from Intel's side: There's several ways to improve the performance of a CPU.  You can add clockspeed, you can make each instruction (and therefore clock cycle) more powerful, or you can add cores.  Each of these allows the CPU to perform more work per unit time.  Making instructions more powerful at this point is only marginal effects (and several of Intel's latest attempts have backfired - SPECTRE comes to mind...).  We're near physical limits for clockspeed - so adding cores is the easiest and most straightforward way to make more powerful CPUs at present.

I believe current KSP (in just the last few versions) has gone multithreaded for physics - in the 'one thread per ship' method.

Share this post


Link to post
Share on other sites
3 hours ago, DStaal said:

Two reasons why Intel went with more cores: First off, your computer is doing a lot more than just running the program you're interacting with.  Having additional cores for background processes, OS process, etc. makes sense.  Secondly - from Intel's side: There's several ways to improve the performance of a CPU.  You can add clockspeed, you can make each instruction (and therefore clock cycle) more powerful, or you can add cores.  Each of these allows the CPU to perform more work per unit time.  Making instructions more powerful at this point is only marginal effects (and several of Intel's latest attempts have backfired - SPECTRE comes to mind...).  We're near physical limits for clockspeed - so adding cores is the easiest and most straightforward way to make more powerful CPUs at present.

I believe current KSP (in just the last few versions) has gone multithreaded for physics - in the 'one thread per ship' method.

Ive heard that about 1 thread per ship but have not seen any practical performance differences with it. I'm not sure if that is true or not. 

Edited by dave1904

Share this post


Link to post
Share on other sites
10 hours ago, Master39 said:

The CE takes a lot of backslash because of its graphics when Interaction wise it's one of the most advanced.

Oblivion had single pickable and readable books in bookcases when the most graphically advanced games of the time were using static models or even 2d textures with the bookshelf drawn on, Skyrim has all the props to be physic based instead of being glued in place like in most other games and F76 managed to get the CE working in multiplayer on the same hardware that runs F4 which is a miracle on its own.

When you hear someone blaming the game engine you can always be sure they don't know what they're talking about, especially with Unity and the Creation Engine.

That was kind of my point. 

Monernised skyrim when worked on by largly unpayed modders many of whome dont actualy have the credetisls to get hiered by bethesds,*can make a old game engine look good....while payed profestional can only make a suposedly turbocharged updated and modernisef engine that they suposedly updated.....look like total crap.....never mind bugs that dated bact to Skyim and were fixed by comunity mods years ago.

Often it turns out its not the tools used by dev teams that result in vrapy games.....

And for thre ecord, one of the highest downloaded mods was created by someone who was 13 at the time. Another just got her GED this year. 

Share this post


Link to post
Share on other sites
16 hours ago, Francois424 said:

With the lootboxes and other garbage, games haven't improved much (graphics-wise) in the last ~10 years IMHO.  And it's a darned shame.

... Forza and Microsoft Flight Simulator much?

(and ray tracing?)

10 years ago we had this

pySc4mK.jpg

and this

U956GJq.jpg

as AAA games (Forza Motorsport 3 and Halo 3 ODST, respectively);

now we have 

H6GnHff.jpg

HhrI6xw.png

and

g8UepHW.jpg

as AAA games (Battlefield V RTX, Microsoft Flight Simulator 2020*, and Forza Horizon 4)

 

No, we've gotten really, really good at photo-realistic graphics. It's these next 10 years that'll be a problem.

 

 

But as for the Unity discussion, the Forza engine might be better, but only Microsoft can use that.

*This hasn't been released yet, but it's from the real-footage trailer. It was the best one I could find, but in the trailer, there's a shot of storm clouds that's actually stunning. I'm sure y'all have seen it tho

Edited by Concodroid

Share this post


Link to post
Share on other sites

Some amazing knowledge in this post and I appreciate you all sharing it with us. 


Back on topic,  all these features sound amazing.  Is there anything in existence showing current (modern) versions of a 3D Unity Game that don't look like the "10 years ago" images above?   Even Subnautica wasn't far off Halo 3. 

 

201803_SN_B84_Splash-618x348.jpg

Share this post


Link to post
Share on other sites
2 hours ago, ronson49 said:

Is there anything in existence showing current (modern) versions of a 3D Unity Game that don't look like the "10 years ago" images above?

Escape from Tarkov is a Unity game, and it looked pretty good for a game released in 2016.

Share this post


Link to post
Share on other sites
5 hours ago, ronson49 said:

Even Subnautica wasn't far off Halo 3. 

It depends if you're after photorealism or the stylized look Subnautica was actually going for.  Personally, I think Subnautica was beautiful and would have no problem if KSP also choose a more semi real approach.

Edited by klgraham1013

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.