61–70 of 84 posts
My biggest question: who the hell plays KSP without the orbit map interface?
I watched a streamer play KSP for the first time, not have the patience to learn orbits (at least on stream), just point at the Mun and go for it. I was yelling at the screen that it wouldn't work, but somehow he made it there, though with the same delta-v he could have gone to Eve.
Earlier quoted context omitted.
You can give Simple Rockets 2 a try in the meantime. It uses fully customizable procedural parts (wings, fuel tanks, even engines) instead of premade parts like KSP, it looks a bit nicer and it includes a visual programming environment for your spacecraft (e.g. you can build a SpaceX-like autoland routine).
I've never tried Simple Rocket, could you compare it to KSP? At a glance, it seems more serious than KSP while KSP has a "fun" edge, but besides that they seem more similar than not.
What I love about SR2 is the aerodynamics and the procedural parts. You can create an airplane and design its wings and control surfaces by hand, you can play with the center of gravity, custom fit it with a jet engine (by tweaking the compression and bypass ratios, adding or omitting an afterburner) and just fly some aerobatics.
You can use electric powered rotators and hinges, powered procedural wheels for cars and other cool stuff. And if everything else fails, your rocket is saved is a plain and simple XML file, so it's easy to just dig in and tweak some more.
On the other hand, there is no campaign yet and only a bunch of tutorial-like-tasks to get you started (take off, reach speed X, achieve orbit, hit the Moon with your spaceship etc).
I wouldn't say that either game is better, SR2 is just different and provides you with some more freedom and options than vanilla KSP.
Also KSP is Windows + Mac + Linux + consoles, while SR2 is Windows + Mac + iOS + Android, and the mobile versions are surprisingly playable (especially on tablets or larger phones).
Earlier quoted context omitted.
An interesting piece of industry-insider information, at least as far as I recall from the Sony pub regulars I knew back in the day: the colloquial term for the polar artefact you describe is the cat’s bumhole .
One way around this is cube-mapping. You construct a cube then normalize all the vertices to "over-inflate" it until it's a sphere. Then you have six textures mapped to the faces of the cube, and no cat's bumhole, and no international date-line zipper. If you subdivide the faces of the cube into rectangles via equal angles instead of naively into a grid, then cut each of the rectangles into two triangles by the short…
Earlier quoted context omitted.
I've never tried Simple Rocket, could you compare it to KSP? At a glance, it seems more serious than KSP while KSP has a "fun" edge, but besides that they seem more similar than not.
SR2 is a little bit more serious than KSP, I'd say, but it's no Orbiter either. They use a smaller-size solar system (bigger than KSP though) by default (you can swap it out for a community created realistic system in-game), so you can still brute-force to orbit or build a SSTO and it will kinda work. What I love about SR2 is the aerodynamics and the procedural parts. You can create an airplane and design its wings a…
Space rendering is full of interesting problems like this. Another one is that single precision floating point doesn't have enough precision to represent both planet scale and human scale in the same coordinate system (let alone solar system scale or galaxy scale), yet GPUs don't support double precision well. So you have to make sure that you do calculations needing high precision on the CPU in double precision and…
> yet GPUs don't support double precision well. Are there GPUs without FP64 functionality at all? Or are you just referring to most consumer GPUs being built for FP32 performance over FP64?
Earlier quoted context omitted.
KSP's approach to the precision problem is surprisingly simple: whenever you get more than two kilometers away from the origin, move the entire universe two kilometers so that the location of your craft, and all the physics-relevant computations on it, have small numbers as coordinates. (This fix was known as Krakensbane: it solved a bug known as the Deep-Space Kraken, which was essentially that floating-point physic…
Pretty sure that the floating origin moves with the craft now every frame. The entire universe also orbits around the craft when it is below the inverse rotation altitude threshold, which means that PhysX is doing physics in the co-rotating reference frame. That means that the "First point of Ares" -- normally (1,0,0) -- rotates around the z-axis as the craft moves and you have to query Planitarium.right to determine…
Earlier quoted context omitted.
KSP's approach to the precision problem is surprisingly simple: whenever you get more than two kilometers away from the origin, move the entire universe two kilometers so that the location of your craft, and all the physics-relevant computations on it, have small numbers as coordinates. (This fix was known as Krakensbane: it solved a bug known as the Deep-Space Kraken, which was essentially that floating-point physic…
That's interesting. It doesn't sound that simple though, I imagine there are some gotchas with that. They are probably constrained by what Unity allows. In my custom engine I did the world to camera transform for each object on the CPU in double precision, essentially making the camera the origin for all subsequent single precision computations on the GPU. That works for small objects and even large objects that are…
Earlier quoted context omitted.
> yet GPUs don't support double precision well. Are there GPUs without FP64 functionality at all? Or are you just referring to most consumer GPUs being built for FP32 performance over FP64?
There are many GPUs with no double precision floating point support in hardware. Modern ones can probably emulate it. Older ones don't have any explicit support. Most real time 3D renderers do not use double precision at all.
Which ones? I'm genuinely curious about this.
Earlier quoted context omitted.
> It's not like you need to update orbits nearly as often as part physics. The max time warp is 100000x, and at that speed if you updated orbits every 10 game seconds that would only be 400 calculations per tick, per craft. So without that simplification you might need a smaller cap on satellite swarms, or a max speed of 10000x, but time warp would still be well inside the realm of "possible". KSP's most well-known n…
> The Keplerian curve no longer applies once you introduce additional influences, though, so it doesn't really matter how (in)frequently updates are applied for those other influences. It depends on how well you can simplify the math. I would imagine that instead of an n body calculation it's lot simpler to calculate the influence from one body plus one unchanging vector, but I've never tried it. > The approximation…
I think what you describe could either be Euler's three-body problem (two fixed point masses and a particle) [0], or the restricted three-body problem (two point masses and a particle) in a rotating/pulsating reference frame. The former does have exact solutions, and I don't believe the latter does, though I'm admittedly not familiar with the literature. I'm also not sure how easy/hard it is to evaluate the exact solution, and how the difficulty compares to proper n-body integration.
That being said, I think using Euler's three-body problem would result in losing some potentially useful n-body effects. For example, centrifugal/centripetal forces would be missing compared to a restricted three-body problem in a rotating reference frame, so Lagrange points might not be present. There might be other effects I'm not aware of as well.
> Not a problem because if you're not close to anything then your orbit won't be chaotic.
I'm not sure I understand why being farther away from something would result in less chaotic trajectories? If anything, I'd expect more interesting orbits due to the lack of one dominating influence.
[0]: https://en.wikipedia.org/wiki/Euler%27s_three-body_problem