Jump to content

Developer Insights #18 - Graphics of Early Access KSP2


Intercept Games

Recommended Posts

21 hours ago, PDCWolf said:

I can't believe the stuff I'm reading. PQS being limited garbage was known before KSP1 got to 1.0, and then y'all went and wasted time on it only to obviously have to throw it away

Probably wasn't ready and they didn't want to release KSP2 at the imposed deadline with just a dev console.

[snip]

Edited by Superfluous J
Link to comment
Share on other sites

Those are all reasonable steps and look like a good way forward. I still gotta wonder a bit why some of those choices are being made so far - I'd think replacing the rendering pipeline and the entire terrain render system at this stage is pretty late? Also, what's the turnover at Intercept like if you are in charge of something major like this from the start?

But it sounds very interesting and promising, good luck with the implementation! Might be good to have a Ultra level on top of high and apply some of the savings with a really good frames/quality trade-off to the current high setting.

Link to comment
Share on other sites

Super informative post, and  I and many others super appreciate the openness. What I wonder is at what stage of development did yall realize that PQS wouldnt cut it and you needed to swap to a new system, and how far back ago did you begin the process of starting work on CBT? 

Link to comment
Share on other sites

52 minutes ago, Intercept Games said:

In the medium term, my first major project on this team is to design and build a next-generation terrain system – what we’re calling the CBT system (it uses a Concurrent Binary Tree data structure, but it could also stand for Celestial Body Terrain). PQS+ has served us well, but nowadays video cards are much more flexible and there are more modern approaches that will give us better results in terms of performance and visual quality. Exciting new earth-shaking architectures are possible. The next-gen CBT system will be the topic of a future dev blog which will contain a much more detailed look at what we’re building. While it’s too early to share any details, I will say that I’m excited about the artistic expressiveness, potential terrain variety, and performance of the CBT system. 

Mortoc, I know you preceded this with how you can't make any promises but man oh man does this have me pumped. The celestial bodies do indeed look INCREDIBLE from orbit. They make me excited to get down there and see it up close. As a big fan of having "boots on the ground" and seeing what's just over that next ridge, the current experience on the surface of the CB's is somewhat underwhelming. It's definitely better than KSP1, but the visual leap between KSP1-KSP2 from orbit is much bigger than the between KSP1-KSP2 on the ground.

Link to comment
Share on other sites

1 hour ago, Superfluous J said:

Probably wasn't ready and they didn't want to release KSP2 at the imposed deadline with just a console.

You do realize the graphics department hasn't moved much since the original videos from 2019, right? So it's been at least 3 years this system hasn't been ready, and their PQS Hacks (PQS+? lol) has been in place.

Edited by Vanamonde
Link to comment
Share on other sites

53 minutes ago, Intercept Games said:

this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love). 

I've already started working on an SRP prototype that is a drop-in replacement for the built-in pipeline in an attempt to cut out buffers and leverage SRP batching. I'll be glad to throw this out though! :D 

But HDRP is probably what I'd do if I were doing it from the source code end.  There is just so much better about HDRP than builtin.  But quite a lot of assets are going to have to be reworked.  I can't understate how much of a challenge this is going to be.

 

 

Link to comment
Share on other sites

Nice news that you are going with concurrent binary trees. I have just quickly skimmed through some papers and videos (you've likely already watched them lmao) and it does appear to be a very interesting and very exciting system. Good work and good luck, I cannot wait

Link to comment
Share on other sites

I enjoyed reading this devlog, many thanks. Good to see that what the profilers see checks out with what the community figured out - the high memory dependency and the crushing performance cost of celestial body surfaces.

And by all means, fast-track the CBT and HDRP stuff as much as possible! The game already looks and plays well as long as no planet is in view, so things can only get better from here on out :)

Link to comment
Share on other sites

Thank you! We appreciate you and support you 100%! I am glad you are taking immediate action to improve performance by removing excess baggage. The long game is important but right now we need some quick fixes to get us into orbit!

Edited by twich22
Link to comment
Share on other sites

1 hour ago, Intercept Games said:

Another area that will see a major shift in visual quality and performance is bringing the game up to Unity’s modern renderer, HDRP (read more about HDRP here if you’re curious, it rocks). The main benefits we get from HDRP are a more optimized render engine, which means faster framerates, and a more flexible shader model, which means more effective dev team efforts.

Does this mean having many lights on your ship won't drastically reduce framerate when this is implemented? I was disappointed to see the same technique used in KSP1 be used again in KSP2.

Link to comment
Share on other sites

I'm curious about the mesh topology. Back in the old days (early 2000s) having triangles that varied a lot in shape, or really stretched ones, was bad for physics engines- a previous dev note showed some wires and they were pretty ugly. Just wondering out loud about how modern algorithms handle this and if this is what is being generated currently.

Link to comment
Share on other sites

1 hour ago, PDCWolf said:

I can't believe the stuff I'm reading. PQS being limited garbage was known before KSP1 got to 1.0, and then y'all went and wasted time on it only to obviously have to throw it away?

If I were to make an educated guess even though games are far from my expertise, and based on what was said in the post, they probably used an already implemented system to experiment and try new things they wanted in the renderer. This probably allows them to both trying new things and evaluating the current capabilities, while keeping the work in an already known and familiar environment to be able to iterate much faster.

Also, the words are there: 

1 hour ago, Intercept Games said:

...

KSP2 uses a modified version of PQS from KSP1, generally referred to as PQS+ after all the modifications made to it for KSP2.

...

Clearly the PQS System and related shaders are a big performance problem.

...

the team started with the PQS design from KSP1 and added modern graphics features for KSP2’s PQS+. As development progressed on KSP2, more and more features were added to PQS+ to keep pushing the artistic envelope.  

...

the terrain itself just doesn’t have the consistent visual quality we want yet. While trying to build that ground up to our visual ambitions, we added more features than the previous PQS architecture can support.

...

If I were to keep guessing, they probably already experimented a little with CBT, which is why they quickly decided on the switch once they found that PQS wasn't going to be able to cut it. I'd even say that the switch to CBT is something that probably were discussed internally and decided against it for now... until it didn't.

Then again, that's my own impression, and as I've said I'm a little far from games, so some salt is required ¯\_(ツ)_/¯

Edited by Haustvindr
Link to comment
Share on other sites

frack yeah ! That's the level of communication im expecting during an EA.

It's a relief to read something else than PR repurposed bovine waste. KSP users are intelligent people, they won't get fooled by dumb excrements.

Im looking forward for your next dairy. Keep it technical and explanatory:) ....make me google.
I think we all can agree that the game sucks on it's current state. But people are not mad at the game it self.  Just think that people want to be part of the journey and understand what is going on. 

Edited by binaryFloatingInt
Link to comment
Share on other sites

As happy as I am for the news... it seems like it'd be logical to reconsider if there's any other areas of the game that might be due for a proper refactor like this instead of trying to trudge along old code. I'd hate to see us running into similar walls due to constraints placed by similarly neglected code in other areas of the game!

Link to comment
Share on other sites

13 minutes ago, Haustvindr said:

snip

Your initial paragraph makes sense, until you add in the fact that PQS being limited was something we knew at least 10 years ago. Whilst hardware has improved significantly, terrain remains the biggest source of frame delay in KSP1 (if you don't push partcounts). This has been known for a long time, as the last update to PQS was on 0.20, in the form of "streamlining", and even then it was still easily noticeable that terrain and the PQS system in general was a problem. The appearance of mods like Kopernicus (and back then some non Kopernicus planet mods) made this even more painfully evident.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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.

×
×
  • Create New...