Precision controls and instruments

[tommaster]

Hello,

I'm fairly new here although I have been lurking in the forums for a while.

First off, I enjoy KSP very much it is a fun game. But what I miss most and foremost are better controls for precise maneuvers. The maneuver node interface is nice but it would be even nicer if you could enter precise values instead of clicking and dragging - especially if you're in a big ship (FPS issues) this can be very laggy and frustrating.

Same applies for docking. I managed to dock manually, but I can't be bothered to do it again. I now let MechJeb do its magic after I am in range. The reasons is that the controls are just too flimsy. There's a good amount of guesswork and the only indicator you have is the navbal - which is not very precise at all (lacks resolution for fine tuning).

Now I realize I might be spoiled as I am a veteran Orbiter player and am used to tools like this:

(for docking)

or this:

(for interplanetary travel).

Don't get me wrong, I love KSP (I paid for it), but I sure hope the final release will have some tools that are more on the simulation side (maybe optional).

[Zeroignite]

You might wanna grab MechJeb. All the orbital info you'll ever want

[tommaster]

I do have MechJeb - I would go nuts without it :-)

However, I would like to do more stuff manually if it wasn't so tedious. Simple example: Set your periapsis to a certain value. That's not possible in vanilla atm, something I really hope will be added.

[CosmicX1]

Yeah it would make sense if you could just input values you want into the manoeuvre nodes as well, but you can still get precise values I find if you're just slow and careful when dragging the tabs.

[tommaster]

I actually like the current maneuver node system, too. It's awesome to plot a rough course that you will correct later anyway (like only aiming roughly for a interplanetary intercept since you will do a course correction in mid-travel where the least delta-v is required).

For other things though it is not so useful and if you run into some framerate issues it can become quite frustrating to get the values correct, especially if you're short on time. So just an additional method of manipulating maneuver nodes (numeric input via keyboard) would be great.

[Dunbaratu]

I actually like the current maneuver node system, too. It's awesome to plot a rough course that you will correct later anyway (like only aiming roughly for a interplanetary intercept since you will do a course correction in mid-travel where the least delta-v is required).

For other things though it is not so useful and if you run into some framerate issues it can become quite frustrating to get the values correct, especially if you're short on time. So just an additional method of manipulating maneuver nodes (numeric input via keyboard) would be great.

Keep in mind that some problems with getting things precise are the fault of 32-bit floating point numbers, not the user interface used. When you see your predicted path wiggling all over the place wildly, and can't tell whether your periopsis at intercept with a planet will be 10 km, 90 km, or something in between because the number is wiggling all over the place, Thats not really the interface or the frame rate doing that. It's the

fact that the game is calculating math equations that tend to have large chaotic swings to them, and it's doing so with imprecise 32-bit floating point numbers.

[rkman]

Sounds like a good idea.

In the mean time, there is a mod for that:

http://forum.kerbalspaceprogram.com/showthread.php/42716-0-21-1-Maneuver-Node-Improvement-v1-2b

[tommaster]

Sounds like a good idea.

In the mean time, there is a mod for that:

http://forum.kerbalspaceprogram.com/showthread.php/42716-0-21-1-Maneuver-Node-Improvement-v1-2b

Oh, that looks very nice indeed. Will check it out today, thanks

As for precision; 32bit floats is more than sufficient. No course plotting algorithm is actually simulating the forces from all gravity sources in real time anyway; this is far too complicated even for very powerful computers. Not sure how it's actually computed in KSP but fairly sure it uses estimations like Orbiter does.

[Dunbaratu]

Oh, that looks very nice indeed. Will check it out today, thanks

As for precision; 32bit floats is more than sufficient. No course plotting algorithm is actually simulating the forces from all gravity sources in real time anyway; this is far too complicated even for very powerful computers. Not sure how it's actually computed in KSP but fairly sure it uses estimations like Orbiter does.

Error cascades and gets bigger with each calculation. It doesn't take a lot for +/- 0.00001 to turn into +/- 0.0001 to turn into +/- 0.001 to turn into +/- 0.01 to turn into +/- 0.1 to turn into +/- 1.0 to turn into +/- 10.0 and so on. And it doesn't take difficult math, just repetitive math - the sort of things computers are VERY fast at doing.

[technicalfool]

imprecise 32-bit floating point numbers.

That's a thought.. are Squad using floats (32 bit) or doubles (64 bit) here, and what would the performance hit be of switching everything to doubles? I'm guessing at some point, a 64 bit version of KSP will be released, and it'd be silly not to be using the 64 bit values by then.

[Dunbaratu]

That's a thought.. are Squad using floats (32 bit) or doubles (64 bit) here, and what would the performance hit be of switching everything to doubles? I'm guessing at some point, a 64 bit version of KSP will be released, and it'd be silly not to be using the 64 bit values by then.

In 32-bit code, doubles multiplication take extra clock cycles to calculate because they are calculated in two halves.. In 64-bit code they do not as the entire calculation happens at once in parallel in a single instruction.

[pizzaoverhead]

Sounds like a good idea.

In the mean time, there is a mod for that:

http://forum.kerbalspaceprogram.com/showthread.php/42716-0-21-1-Maneuver-Node-Improvement-v1-2b

Following on to this, there is also a mod which provides a docking display: NavyFish's Docking Port Alignment Indicator.

[pa1983]

SSE2 has twice the registers available in 64bit mode then 32bit so even that should speed up code with vector operations.

Also Im not so sure running 32bit code half's the GFLOP performance.

x87 was 80bit floating point unit so fare beyond 32bit and was capable of double precision natively.

x86 processors also fetch data from memory at 64bit a time and has a 64bit wide L1 cache line.

Theres no reason that a 32bit CPU cant execute 64bit or longer floating point operations. The instructions can be 32bit or like CISC variable length anywhere in between 1 and 32bit.

Even a 32bit CPU could work natively on 64bit of data or longer if it has execution units and registers for that. If I recall SSE2 is 128bit and can hold 2x 64bit double precision number or even integers. It could also hold 4x 32bit etc. So I suppose it could do twice the GFLOPS at 32bit but that would just be single precision so actual single or double precision would not be effected.

AVX is 256bit and can hold 4x 64bit double at once in its registers.

I tested intel linpack 32bit on my i7 3930K @ 4Ghz and got 136GFLOPS VS 160GFLOPS with 64bit so its slower but not half as slow but from what I read just like SSE2 you get half the registers available in 32bit mode compared to 64bit mode so that would mean less instructions would be used to load and store data in registers to work on a vector and more instructions could be used to manipulate the data in the registers in stead between loads and stores.

But Im no expert but thats my toughs on it. 64bit should be faster either way assuming the most frequently used code in KSP is the one optimized to take advantage off a modern processor.

Right now its physics that is slow so that needs a speed boost by utilizing the CPU at its best, AVX and multithreading should not hurt there but Im no programmer but the Floating Point performances twice that of SSE2,3,4 so from a pure number crunching having AVX and use say 4 cores for physics should in theory give it 8 times the GFLOPS performance assuming physics has its own core now but it docent so in theory even bigger gain. But in reality multi threading dont scale linear most of the time.

But if you dont need double precision single precision makes the most sens to get the most number crunching done. You could still use 32bit single precision floats with 64bit binary and get twice the registers to work with in SSE2 and AVX.

If Im wrong on something here pleas correct me it was a long time ago sense I read up on any of this.

Edited August 16, 2013 by pa1983

[Hannu]

Floating point units have used 80 bit registers decades. I have taught in 90's that 32 bit float datatype have no time advance compared to double and it should be use only if you have huge array of numbers and limited amount of memory. Processor converts 32 bit floats (and also 64 bit standard doubles) to internal 80 bit format before any calculations and just store 32 bit values in memory. I made once solar system simulator and found that even double's accuracy is limited and it had to take into account in code.

[pa1983]

80bit for x87 in a x86 CPU that is. Its actually uncommon for anything else the x86. Most other CPU architectures either support 32bit or 64bit FPU's and registers. Also most programs sens the Pentium 4 should according to intel use SSE2 instead of x87 and MMX sens its been deprecated sens 2001 with the introduction of the Pentium 4 and SSE2 sens SSE2 is a direct replacement for x87 tough not compatible in terms of instructions the instructions can fill the same function and more. Most compilers according to intel should generate at least SSE2 as default and x86_64 its a requirement sense its a part of the x86_64 standard. Most IEEE standards for floating point operations is for 32 or 64bit from what I know. Dont think 80bit x87 is IEEE.

SSE2, AVX etc from what I can read works with 32bit, 64bit segments in its registers, maybe 16bit/8bit to I not sure but sens you actually tells the compiler the length in C or C++ from the little coding I have tested there are half words, word and double word available. But I never got beyond making small 15-20 line programs that could add a few numbers and spit out the result. Coding was not realy my thing with dyslexia and having a hard time spelling stuff properly and coding is unforgiving and well not the talent for it. Tough I love how computers work on a logic level.

Edited August 16, 2013 by pa1983

[Nuke]

id love to see avx support, but i bet its one of those things that needs to be supported by unity. sse2 has been around for awhile and that is probibly what unity currently is using.

[pa1983]

Think the big problem is physx. Was not that long ago they went from x87 to sse2. Avx is probably long time away.

I dont know how smart compilers are even if I use gentoo linux but from my understanding the compiler tries to optimize best it can.

[Nuke]

physx would actually benefit most from the avx instructions. but i doubt the version that comes with unity is cutting edge release. i think of it more as the stripped down and gutted version that is based off of an older branch.

[Hannu]

80bit for x87 in a x86 CPU that is. Its actually uncommon for anything else the x86.

OK. I thought that it is common, because Motorola's floating point processors (68882 etc.) used also 80 bit floating point numbers (20 years ago). However, point was that it is stupid to use 32 bit floats in physics simulations. I know that many thing is possible with them, if coded right way, but in any case they do not give anything compared to 64 bit double. If you have so massive amount of data, that memory is critical thing (that means billions of numbers), you need supercomputer to crunch numbers. In KSP it would mean ridiculous number of ships. It need just 10-20 numbers to represent orbit (or few times of that, if there are many conic patches) in practical way.

It is even more strange, if universal physics engine like PhysX uses floats instead of doubles.

[Nuke]

really depends on the job. floats are good enough for most jobs. and since physics needs to be really fast (cause you are doing a lot of n^2 algorithms), you use a format that can do fast maths, like 32 bit float. if you run into a job that needs a lot of precision, such as collision detecting objects over a wide range of velocities (like what ksp needs to do), then you can trade speed for precision. physx is likely designed with both data types in mind, use the one for the job you need. sorta like how unity's 3d maths come in float and double flavors.

[pa1983]

OK. I thought that it is common, because Motorola's floating point processors (68882 etc.) used also 80 bit floating point numbers (20 years ago). However, point was that it is stupid to use 32 bit floats in physics simulations. I know that many thing is possible with them, if coded right way, but in any case they do not give anything compared to 64 bit double. If you have so massive amount of data, that memory is critical thing (that means billions of numbers), you need supercomputer to crunch numbers. In KSP it would mean ridiculous number of ships. It need just 10-20 numbers to represent orbit (or few times of that, if there are many conic patches) in practical way.

It is even more strange, if universal physics engine like PhysX uses floats instead of doubles.

I didnt say 32bit was good enough. But I do think I read that physx in ksp uses 32bit precision but if thats always the case I dont know. A dev should know. And sure most super computers uses or is at least mesured in 64bit FLOPS performance or was back in the day designed purely for that in many cases.

I did not know the 68882 used 80bit.

But I read that 80bit like the x87 was more uncommon then 32 or 64bit. Also most IEEE standards seems to be for 32 or 64bit from the wiki pages and such I have found.

But how knows maybe that info was incorrect. But it docent make much sens to me why modern CPU's would use 80bit this days when everythign seems to be aimed at 32bit or 64bit precision.

Sure even an i7 can do 80bit sens it has x87 legacy support but Im not sure you can even use it in 64bit mode sense SSE2 is the standard with x86_64. I know some 64bit OS like windows will allow x87 in user space but not in kernel space and it works even in 64bit mode from what I have read.

Edited August 17, 2013 by pa1983