K^2

I think they have a good opportunity to make it run well on gen 9 consoles (PS5/XBS) and it's possible to optimize to run just fine on gen 8 (PS4/XB1), but none of it is going to be "for free" or "out of the box" with Unity. It kind of depends on how much optimization Intercept manages to do. Realistically, I think PS5/XBSX are going to be target platforms, and Intercept will make all effort to make the game run well on these two consoles. This is why I have been using PS5 CPU as a benchmark for what sort of min spec the game will have on PC. But whether Intercept will be fully successful on this remains to be seen. It's a small and young studio, so it's possible they'll try and fail. I don't think we should be taking it for granted that the game will even ship on other platforms at this point, despite initial claims that it will, but if it does, I would realistically expect to have either some cuts or serious performance issues on PS4 and XB1. As I said above, it's possible to optimize the game for these consoles, because there isn't, ultimately, that much going on, but it's going to be a lot of ad-hoc work, so I don't know if the studio has resources for this kind of thing. Basically, I wouldn't hold out a lot of hope for good performance on gen 8, if it ships at all, or PCs of comparable age. You'll very likely need a bit more horse power there. There was a bit of a discussion in another thread on whether it can be made to run on Nintendo Switch, and I think even that is doable with the right team, but for Intercept to even attempt that it would require a number of highly specialized hires on a short term, all rather senior, and so it would be very expensive to even attempt. So this one I'm confident isn't on the budget for KSP2. Maybe if it explodes in popularity beyond everyone's expectation, they'll find resources to try and do the port later. It would have to be guaranteed to sell millions of copies to be worth it. (Yeah, we're talking that expensive of a port, given people you'd have to hire.) Or maybe Nintendo releases a beefier version of Switch to stay within reach of gen 5 systems. Either way, I wouldn't hold my breath for this one. Realistically, if you'll want to play KSP2 portable, you'll probably want to stream it, or maybe invest in a handheld PC. Both GPD WIN3 and AYA NEO fall considerably short of PS5 CPU, but primarily on core counts. Single thread performance is comparable, and I expect that will still matter a lot for KSP2. So these handhelds might just hit the mark for min spec of PC version of KSP2, and hopefully, better handheld gaming PCs will start showing up in the next year or so. Of course, I suspect prices will stay decisively in PC-gaming ranges.

I haven't even considered the possibility of it starting out uncooked. But now I'm thinking that it depends on size of the rocket. Like, with the smallest ones, maybe it takes a few launches to even cook through. Which brings up a serious question. I wonder if we'll have any parts of colonies or KSC that require rebuilding due to wear-and-tear. In KSP we already had a possibility of crashing into KSP buildings and having to rebuild them. But it was always the same building in the same location. With base-building, it seems reasonable that you might rebuild differently. And given that you can rebuild things, maybe certain structures have limited lifespan? Maybe instead of a hard limit on rocket size for a launch pad, you could go a bit over the limit, but then you have to repair/rebuild after some number of launches? Too complex for main game? Mod territory, perhaps?

Yeah, Parallax looks amazing. I think, the way the mod achieves this look is pretty expensive and has very limited impact on physics, but it's all very doable to have in stock KSP2 with minimal overhead if Intercept goes with virtual texturing, dynamic tessellation, and compute for wheel and leg collision probes to allow for these small bumps to actually have effect on physics. I've seen something similar run on PS4 at very good performance, and it's no trouble at all for gen 9 consoles and most remotely modern PCs.

Oh, it doesn't matter what shape on 2D you are mapping to - just that it's a 2D shape. The problem is that to have a nice mapping, you need open sets to map into open sets. It's possible to show that it's impossible to do so for a sphere with a single projection. At an absolute best, you can map all but one point with a single mapping. An unwrapped cube effectively has 6 different mappings - one for each face. Which is perfectly fine. But it still means you'll have trouble at points where multiple mappings come together. For a cube, that's your 8 original vertices of the cube. Sorry that I'm being a bit hand-wavy about what a "nice mapping" means and why open sets matter. If you want to chase this down, the relevant topic is differential geometry (or differential topology). You'll want at least a minimal intro to topology for that, for which you'll want an intro to real analysis and just a touch of measure theory. And you can probably get through both if you have a solid background in calculus. I'm sorry if it's coming out as a bit pretentious, but differential geometry is one of these subjects where math gets so abstract that it's only worth to either just state some results as facts or, if you really want to understand it, to go through and learn the background. If there's a way to give simplified explanations, I don't know it. Maybe I'm just not good enough at the subject, but it's best I can do. Edit: I think I have an illustration for where things go wrong, though. Imagine that you have a sphere. Imagine that you are texturing it by mapping sphere to a cube, then unwrapping the cube to a 2D texture. Now, picture that you started drawing a straight line on a sphere (technically, a great circle). What happens to that line as it crosses from one cube face to another on your texture? Well, the line will probably not look straight, which isn't a big deal. But when it crosses from one cube face to another, it's going to get a sharp kink. The orientation of the tangent at that point becomes discontinuous. In general, a smooth curve on a sphere isn't guaranteed to be a smooth curve on the texture and vice versa. Which isn't a disaster, but it can lead to artifacts if you aren't careful. And that's a big part of why even though you are using a single texture for your unwrapped cube, you really have to treat the 6 regions corresponding to each face as a distinct mapping.

Now I want there to be a hidden launch facility in the woods made out of gingerbread.

It's not all that straight forward. The actual terrain you are going to render is going to have sub-meter resolution to look good. Even at Kerbin size, you aren't going to have a world texture like this. So you are always going to have a texture defining coarse features with some material tiling and possibly procedurals defining local geometry and texturing of terrain. Granted, when rendered from great altitude, an icosphere makes it way, way easier to just have a few subdivisions, slap a texture over it, and have a nice looking planet. But I'd argue that this is also when you care the least both about distortion and about the rendering time. Rendering a planet from high orbit is cheap. Lighting and atmosphere can get expensive, but that's all done at pixel stage and, hopefully, entirely deferred. So no connection to the mapping. Mapping is going to matter primarily when you are on the ground or flying low over terrain. And a quad mesh can actually simplify a lot of that. Yeah, doing a great job of fixing up the valence 3 corners is going to be hard, and might create overhead, but if you are ok with them being a little meh, maybe even design your maps to conceal it - like, if it's oceans at all 8 corners on Kerbin, and maybe some crater features on other planets, then maybe you're ok with that, and you want to go with a much simpler, more performant approach. On the other hand, yes, icosphere will make things way more uniform, and you won't have to try and hide the seams. But it will require more complex math for things like LoD tiling and smoothing as well as texture lookups for coarse features. I'm with you overall. I do think icosphere gives a more elegant, more consistent solution, and it can be more performant at the same quality. But I don't think it's going to be a performance win if Intercept is happy to hide some seams with creative design. Especially, if they don't make much improvement on the underlying terrain tech compared to KSP. In the perfect world, it'd be all virtual textures, hardware tessellation, and compute shaders for collisions. In reality, we are probably still going to see just mesh patches both for rendered terrain and collisions. And that's still a lot easier to do with a square(ish) grid.

A bit, but most of it is going to be in shader, so it being Unity won't matter. It's going to be native code running on the GPU, and as we know with KSP, graphics is where you have some breathing room with these kinds of games. You do need to build terrain collision, which does reside in system memory, but I would still advise building the geometry with compute shader and then exporting it from VRAM to system RAM. Since terrain collision generation isn't done every frame, having to move data from GPU to CPU isn't going to be a bottleneck even on systems with discrete graphics. And Unity does provide a way to do all of this.

Really? I've always heard it as it taking more energy. But maybe it's from the same category as "10 % of your brain." Curious. I'll do some Googling later.

The problem with mapping onto a sphere is that a sphere has topological charge of +2, while a flat plane has topological charge 0. That means that no matter what you do, there will be a distortion, and it has to be concentrated somewhere. (Closely related to Hairy Ball Theorem. [snip] Worse, if you are dealing with a mesh, the distortion has to be concentrated in discrete points. And now you are playing a game of balancing it out. The good thing about polar projection is that all of the topological charge is concentrated at the poles at +1 each. That's a lot of distortion, but it's all in a place you least care about. Who even wants to go to the poles? There's nothing there but ice! Of course, in KSP, we have other planets to visit, and they might actually have exciting poles. Cubic projection has 8 points on which the charge is concentrated. These are your valence 3 verts on a quad mesh. A valence of 3 on a quad mesh always gives you a +1/4 charge, so this adds up to +2 total on the quad sphere. For anyone doing 3D graphics, btw, yes, that will always hold if you take a closed shape that can be "inflated" into a sphere-ish shape. So when you're making a quad mesh for character, if you take all your valence 3 verts and subtract all your valence 5 verts, you'll get 8, because that +2 charge has to go somewhere. And it's always +1/4 for every valence less than 4 and -1/4 for every valence over 4. And that's why they talk about mesh topology. Which, naturally, brings us to triangular meshes, where neutral valence is 6, and anything with valence 5 gives you +1/6 charge. And, of course, the shape we all know and love with exactly 12 valence 5 vertices - the icosahedron. And just like you can take a cube and inflate it into a cube sphere, you can take an icosahedron and inflate it into an aptly named icosphere. The advantage of icosphere is that it distributes the distortion most evenly. The disadvantage is that the mapping is all over the place and it won't pack into a rectangular texture very well. You also have the distortions show up in 12 locations total. Two of them are trivially shoved into poles, but that still leaves you with 10 in the subtropics. With the cubic map, there is a lot of distortion around the 8 points, and shoving any 2 into polar regions kind of defeats the simplicity of cubic mapping, so you end up getting stuck with four in each hemisphere, not far enough North not to cause some visual artifacts. But it is way, way easier to implement efficiently than the icosphere, which is why cubic maps show up all over the place. One of the neat examples is Space Engineers. Their voxel planets are cube-mapped. It's even easier to see that in their Medieval Engineers game which is set on a voxel planet for no reason other than to show off, and you actually get a world map, which is broken down into 6 "square" regions. On the net, I think either a cube sphere or an icosphere would be an improvement, and I guess cube would be easier, as much as I prefer the elegance of icosphere.

You don't need anti-mass for that. Just anti-calories. And we already have that. It's called celery. Some scientists also speculated about using Casimir Effect to add anti-calories to food, but that remains entirely theoretical.

You just did more math than the page author did in their entire life. But I do like that negative mass take. I bet a lot of the designs can be fixed with that. Worst case scenario, you can always weld some mass to some negative mass, place that inside of electromagnet, and just use it to dump momentum. It's like a reaction wheel, but for linear movement. It basically solves every problem. Need a bit of extra thrust? Dump some momentum. Need to take off without noise and debris? Dump some momentum while still on the ground, then sip it gently for continuous hover. Need to raise orbit? Borrow some momentum and periapsis and dump it back at apoapsis. Need artificial gravity on board? Give the ship a gentle spin, then start dumping momentum for constant 1G on board and no net saturation. Then give me quarter impulse, Lieutenant Sulu.

A plane cannot fly backwards. Everyone knows that!

November '22 would be a pretty good window. KSP doesn't compete with blockbusters directly, so it's not actually a bad time. And based on current trajectory, there's a good chance that the game will be ready to ship by then. Of course, additional delays are always possible, but my guess is that late '22 is still the target. This gives Intercept almost a year until feature lockdown and 4-5 months polish time before submit. And the only thing that's at risk on this schedule is multiplayer, which doesn't strictly speaking have to ship in full at release. If it's a choice between delaying the game further and shipping with very limited or even disabled MP, I think later is the better call.

They explicitly mention General Atomics as part of the venture. GA have long standing nuclear projects under DoE oversight, and you might know them from Project Orion. Yes, that Project Orion.

Current mass, also known as bare mass or naked mass, is the mass you have to attach to the underlying field itself, like, a mass a particle would still have if it interacted with absolutely nothing but gravity. Dynamic mass is what comes out from all the interaction. In the simplest terms, if you take an electron and you accelerate it, you aren't accelerating just the particle, but the electromagnetic field around it as well. So a particle with any sort of charge acts as if it's heavier, and in most contexts, that's the mass we actually care about. 511keV is the energy of electron itself plus all the vacuum junk that is dragged along with it. The reason this rarely comes up is because the electromagnetic correction to electron mass is less than 1%. But then constituent mass of quarks in a proton or neutron is almost entirely dynamic, with current mass of quarks being comparatively tiny. On the thread topic, I just saw a pretty good video by Sixty Symbols on the muon shenanigans. Some of it is understandably hand-wavy, but it covers the bases, so it's a good watch. One interesting thing they mention that might be raising some eyebrows is the fact that lattice QCD is done in Euclidian metric. The idea there is that you take time to be imaginary. This lets you replace Minkowski space-time with Euclidian space-time, but then every oscillation becomes a decay instead. The reason it's actually great is that contributions with higher energies decay faster. So as you evolve the system, such simulations tend towards ground state. Therefore, they are really good about answering questions about configurations of particles and vacuum in the ground state. Of course, you have to do a ton of math to convert between the two metrics and to get final results, but on the plus side, you don't have to try and solve a differential equation in 4 dimensions. Instead, you start with an arbitrary "guess" in 3 dimensions and evolve it until it's in the ground state, which is the solution you are looking for. And since the biggest limitation of lattice QCD is number of lattice points you can consider, going from 4D to 3D is actually a huge win.

Yeah, but they're bosons. They're allowed. On a more serious tone, I should probably be distinguishing between current mass and dynamic mass. Z and Higgs' mass is entirely dynamically generated. All of the leptons have a non-zero current mass, as far as we can tell from the models. So the mass is inherent to the particle, not just consequence of its interaction with vacuum, as it is for neutral bosons. You can think of Z as a massless particle wearing very heavy jacket. In fact, the only reason photon is massless is because of the symmetry break due to Higgs mechanism. So it's less that photons have no mass, and more that we call the part of electro-weak interaction that ended up naked the "photons". And so it happens that electromagnetic interactions get an infinite range and infinite fame, and the weak part is, well, weak. But yeah, we're definitely getting into the territory of interpretations, so things are bound to be fuzzy. And I don't remember last time I cared about whether something is a particle or anti-particle. If you aren't happy, flip the diagram over. If it's still not working for you, try turning the diagram 90°. That decay is a scattering problem now. How nice.

I might be repeating myself, so here's a quote from Biofuel topic. On a more serious note, I don't mind a bit of minimal pop management for colonies, like needing to build some number of habitats, etc, but anything more serious seems overkill. Seems like it'd detract from the main game.

Yeah, I think it's pretty safe to say that at least sandbox will be alright. Even if it ends up having as much Kraken as early KSP, so long as there are interesting planets to explore, it's a game. So the baseline isn't bad, and the fact that there's only up to go from there is encouraging. And IMO, landing just one of the following: solid multiplayer, improved physics for large ships and colonies, or good story progression - would push it into a good game overall territory.

I mean, in terms of visual fidelity, it seemed like this is a pretty safe project. I'm still worried about gameplay systems and physics, and we've seen almost none of that. And this isn't an, "I expect this will be a disaster," type of worry. I see a lot of doomsayers here, and there hasn't really been any serious red flags to warrant that. But there's definitely a lot of room between a passable game with mediocre, uninspired gameplay, and something brilliant that will become an instant classic. We haven't seen anything that would indicate progress towards the later, and while Intercept by no means has to have something to show us in that regard, or even be in any way obliged to show us what they do have, the confidence in the game aspects of KSP2 is on good faith only at this point.

Modern game development is oriented to vertical slices. That means driving subsets of features to polish until you have a full game, rather than gradually improving everything. Intercept has been showing us things selectively that are near their final state, which is why you are getting impression that the game is polished.

In the way particles are usually interpreted in Standard Model, a particle has to be massless to be its own antiparticle. There's also the fact that neutrinos come with predominant handedness, and that strongly suggests that neutrinos and antineutrinos are distinct. (Otherwise, we'd expect equal distributions by CPT.) So there is strong indication that they probably aren't their own antiparticles. If we find an experiment that strongly suggests they are, we'd have some explaining to do. To put it in classical terms, it'd be a bit like discovering that Saturn came from outside the Solar System. We'd have to do a lot of new research to figure out how the heck did that get past us, and come up with entirely new models for early Solar System formation, but it wouldn't change our understanding of gravity and orbital mechanics.

Well, yeah. But that's absolutely obvious to anyone who works in particle physics. I mean, it took me a moment to even figure out what you are finding surprising about this. Think about it this way. Lets suppose that neutrino oscillation frequency actually depended on neutrino energy. That would imply that in neutrino's rest frame its oscillation frequency changes depending on how fast the neutrino's rest frame is moving relative to some reference frame. Id est, you'd be measuring the absolute speed of neutrino. The fact that physical quantities cannot depend on energy of a particle other than by Lorentz factor is fundamental result of Special Relativity and gets knocked into your head when you study particle physics within the first few lectures. This is your basic assumption that you get used to applying without even thinking, because it goes for absolutely everything. Frequencies, decay times, etc. In fact, the reason flavor oscillations were a big deal is precisely because of that. The part people rarely add, because it's obvious to everyone in the trade, is that if the oscillations are being measured at all, some amount of time passes in neutrino proper frame. You can't have oscillations if you don't have proper time. And you can't have proper time if you are moving at light speed. So yes, observing oscillations means neutrinos have mass, and if you could measure that frequency precisely at different energies, you'll know the exact mass of neutrinos. Even if we didn't have all the rest of Standard Model, simply knowing the Lorentz factor gives you energy-to-mass ratio, so you'll know precise mass of neutrinos. This is just goes-without-saying kind of thing in particle physics.

Elite is self-published, so it deserves benefit of the doubt, but I don't know enough about Frontier to really have an opinion on whether they need it or not, and whether this is good-faith early access or a money grab. I don't mean to make it sound like things are always black-and-white. Sometimes, you even see games on Kickstarter that have serious publishers behind them, but a successful Kickstarter could be a condition for publishers backing the project in the first place in some rare cases. It can be a way for publishers to gauge public interest to see if a game is worth financing when it's somewhat of a niche title. But early sales have also been exploited to make money on titles that turn out to be no good. Any copy you sell before the reviews are in is a sale you didn't lose due to game's quality. This is why I'm always very skeptical of any pre-orders, especially ones driven by hype and/or pre-order bonuses. Even as a developer, I really wish that practice would go away. I know marketing is necessary for game's success, sadly, and some amount of development effort will always be diverted to it. But pre-order bonuses, especially pre-order betas, take away a lot of resources that would be better spent on making sure we ship a polished product. Even little things, like pre-order only skins for characters can be a nuisance when the deadlines are tight. I can't tell you how many times I've watched critical engineering resources being spent at the last moment trying to fix a bug related to unlocking specific pre-order content on specific platforms instead of fixing bugs related to gameplay, because we are contractually obliged to ship these pre-order bonuses, and so it ends up higher priority than things that actually break the game. And yes, sometimes this is result of poor planning, but because these things often involve 3rd party APIs, these problems can arise at no fault of developer, because there really was no way to test if it's working until weeks or even days before release. So every case is different, and you might have to do a bit of research. Usually, you can tell if a particular early sale is aimed at helping make the game or just improve investment safety margins for some mega corp. Sometimes, you can't tell, and it's a judgement call. And even in cases where it's clear, and people are just buying into the hype and fear of missing out, I don't think it's fair to hold it against anyone. Been there myself. Sometimes, you really, really have to have that pre-order exclusive. I just wish it happens less, so that publishers don't push it on developers nearly as much.

Well, the reason I don't like the idea of placing arbitrary boundary on distance is because it might make it difficult for a mod to place something waaay out in the distance. I think a reasonable solution would be to do origin relocation in two jumps. First places coordinate origin at the nearest star. Second places the simulation/rendering origin at the craft. This basically means that distances can get a tiny bit wonky really, really far between stars, but you won't have a point of reference to notice. And you won't get krakeened anyways, since all your physics is relative to craft's center of mass. And once you get closer to another star, you'll switch to that one as your reference and everything's fine again. That would allow modders to place things way, way out there. And yeah, maybe if the craft is far enough from any star and is on trajectory that's taking it away from all of them, then maybe it should be considered lost. I just wouldn't base it exclusively on distance from arbitrary zero point.

That's not the kind of problems you start getting. Coordinates are almost always stored in floating point format. We can separately discuss finer points of single vs double precision arithmetic as well as the use of origin relocation in games to avoid the worst of the problems, but the gist of it is that the further you get from (0, 0, 0), the worse the math precision gets. If handled improperly, you start getting camera and various object jitters and physics grows unstable. Eventually, Kraken would get you. Of course, even KSP is large enough that this had to be addressed early on, most likely via relocation. With relocation in place, it's possible to entirely avoid physics problem. Camera behavior is still subject to implementation. But eventually, you'll get to the point where you simply can't move origin anymore at given velocity, and the craft will freeze in place, still showing the velocity, but unable to actually make progress. You'll have to get mighty far before that happens, though, and by then, how would you even know? You'd be too far out to notice any change in your position relative to anything else. So I think it's in the category of problems that aren't.