Other benefits of 64 bit

[stormdot5]

The only reasons for 64 bit for most people seems to be to increase available memory to allow more mods before crashing, or to support constantly growing part counts. I was wondering whether it will also allow increased precision in object positioning in space, for things such as distant object enhancement. It would be great if this could remove the instability of objects. For example, when trying to catch something in interplanetary space that keeps shifting when you change time warp levels. Improving accuracy of multiple SOI changes for gravity assists would also be welcome.

Would this happen with 64 bit in 1.1? Or would things have to be further updated?

[cantab]

I don't think it would. The 32-bit x86 architecture already supports 64-bit "double precision" and 80-bit "extended precision". The 64-bit x86_64 architecture does not actually offer any greater floating-point precision in hardware, so slower software approaches have to be used.

[Hannu2]

2 hours ago, stormdot5 said:

The only reasons for 64 bit for most people seems to be to increase available memory to allow more mods before crashing, or to support constantly growing part counts. I was wondering whether it will also allow increased precision in object positioning in space, for things such as distant object enhancement. It would be great if this could remove the instability of objects. For example, when trying to catch something in interplanetary space that keeps shifting when you change time warp levels. Improving accuracy of multiple SOI changes for gravity assists would also be welcome.

Would this happen with 64 bit in 1.1? Or would things have to be further updated?

No, migrating to 64 bit unity does not affect calculation precision. Very probably there will not be also update because it was a huge work and most players does not seem to suffer current problems. It would be practically KSP 2.0. However, there are many problems in map view and orbital prediction (especially detecting of SOI changes) which would be easier to fix and I hope that Squad will do it after updating to Unity 5.

[_Astra_]

30 minutes ago, cantab said:

I don't think it would. The 32-bit x86 architecture already supports 64-bit "double precision" and 80-bit "extended precision". The 64-bit x86_64 architecture does not actually offer any greater floating-point precision in hardware, so slower software approaches have to be used.

 

The x86 does, but the graphics hardware generally does not.

Or it imlies a special performance penalty on these types.

 

Don't see any reason for doubles and long doubles unless Squad adds the Lagrange points to the game...

 

But multiple spheres of influence can really help - many times had the orbit calculator  stick to Mun on my way to Minmus. 

Edited December 15, 2015 by _Astra_

[Hannu2]

1 hour ago, _Astra_ said:

Don't see any reason for doubles and long doubles unless Squad adds the Lagrange points to the game...

But multiple spheres of influence can really help - many times had the orbit calculator  stick to Mun on my way to Minmus. 

Using of doubles would benefit significantly all functions of orbital predictions. It is extremely stupid thing that Squad did not use doubles from very beginning in this kind of work. But the choice is done and it would be far too expensive to change it now. We have to live with poor accuracy. However, it is no reason not to fix buggy and information poor map view. It could be very much better with smallish fixes, if Squad wanted to improve it. I understand that they concentrate every thought in migration now, but after that they could improve many small things which makes game better to play.

If you need just more patches, edit settings.cfg. There is row "CONIC_PATCH_LIMIT = 3". Change that number whatever you want but do not expect accuracy. Adjust every maneuver after every SOI change.

[Red Iron Crown]

17 minutes ago, Hannu2 said:

Using of doubles would benefit significantly all functions of orbital predictions. It is extremely stupid thing that Squad did not use doubles from very beginning in this kind of work. But the choice is done and it would be far too expensive to change it now. We have to live with poor accuracy. However, it is no reason not to fix buggy and information poor map view. It could be very much better with smallish fixes, if Squad wanted to improve it. I understand that they concentrate every thought in migration now, but after that they could improve many small things which makes game better to play.

The on-rails calculations are done with doubles already, the off-rails stuff is done by the Unity physics engine using floats, not something Squad has control over. This is why it's better to do SoI transitions at low timewarp instead of at 1x.

[_Astra_]

3 hours ago, Red Iron Crown said:

The on-rails calculations are done with doubles already, the off-rails stuff is done by the Unity physics engine using floats, not something Squad has control over. This is why it's better to do SoI transitions at low timewarp instead of at 1x.

Red Iron Crown, sounds interesting.

Does it mean that these "on-rails calculations" cannot be offloaded to GPU by design?

 

3 hours ago, Hannu2 said:

Using of doubles would benefit significantly all functions of orbital predictions. It is extremely stupid thing that Squad did not use doubles from very beginning in this kind of work. But the choice is done and it would be far too expensive to change it now. We have to live with poor accuracy. However, it is no reason not to fix buggy and information poor map view. It could be very much better with smallish fixes, if Squad wanted to improve it. I understand that they concentrate every thought in migration now, but after that they could improve many small things which makes game better to play.

If you need just more patches, edit settings.cfg. There is row "CONIC_PATCH_LIMIT = 3". Change that number whatever you want but do not expect accuracy. Adjust every maneuver after every SOI change.

Oh, i tried it! Thanx. Now have 2nd- and 3rd-order orbits  But it's very tricky to pick a correct one.

[Red Iron Crown]

10 minutes ago, _Astra_ said:

Red Iron Crown, sounds interesting.

Does it mean that these "on-rails calculations" cannot be offloaded to GPU by design?

I don't think any of it offloads to the GPU, on rails or off. The on rails calculations are not all that computationally difficult anyway, last time I messed around with performance testing with them (on an old Core 2 Duo) it took about a hundred craft in flight to make any sort of noticeable difference in performance (timewarp has no effect either, the step size just becomes larger).

[Alshain]

No, it does not offload physics to the GPU. Neither Unity 4 or 5 currently support that.  Even if it did, GPU accelerated physics is a one way street, it goes from the CPU to the GPU to the output (your display), so if the game needs the physics calculations for something other than display, it can't be offloaded.  In a nutshell, that means GPU accelerated physics can only offer you graphical flare (cloth animation rendering is a popular example), but regardless of Unity, will NEVER be able to calculate part physics.

Edited December 15, 2015 by Alshain

[cantab]

1 hour ago, Alshain said:

No, it does not offload physics to the GPU. Neither Unity 4 or 5 currently support that.  Even if it did, GPU accelerated physics is a one way street, it goes from the CPU to the GPU to the output (your display), so if the game needs the physics calculations for something other than display, it can't be offloaded.  In a nutshell, that means GPU accelerated physics can only offer you graphical flare (cloth animation rendering is a popular example), but regardless of Unity, will NEVER be able to calculate part physics.

I'm pretty sure that's incorrect. Remember that nVidia's early "Tesla" physics acceleration cards didn't have a display output at all. I'm 99% certain that modern GPUs are capable of processing data and sending results back to the CPU.

The reason I believe that GPU-accelerated physics is mainly seen for graphical shinies is that limited and vendor-specific hardware support means a game cannot rely on it for "core" physics functionality without severely limiting the potential customer base. Though things are getting better in that respect.

Edited December 15, 2015 by cantab

[Alshain]

Just now, cantab said:

I'm pretty sure that's incorrect. Remember that nVidia's early "Tesla" physics acceleration cards didn't have a display output at all. I'm 99% certain that modern GPUs are capable of processing data and sending results back to the CPU.

The reason I believe that GPU-accelerated physics is mainly seen for graphical shinies is that limited and vendor-specific hardware support means a game cannot rely on it for "core" physics functionality without severely limiting the potential customer base.

I'm not sure what "Tesla" cards were.  Aegia, the original creator of PhyX before Nvidia bought them, had PPU's which were installed and operated independently of the GPU.  These too acted as a middle man, but once they rendered something it was sent to the CPU only to be passed along to the GPU through the infrastructure.  Having the PPU built into the GPU is certainly faster as you don't have to bother the CPU again.  But even support for these old Ageia cards required separate infrastructure, the games compatible with them were not automatically compatible with the Nvidia version or vice versa, because they do not quite work the same.

[Hannu2]

15 minutes ago, cantab said:

I'm pretty sure that's incorrect. Remember that nVidia's early "Tesla" physics acceleration cards didn't have a display output at all. I'm 99% certain that modern GPUs are capable of processing data and sending results back to the CPU.

The reason I believe that GPU-accelerated physics is mainly seen for graphical shinies is that limited and vendor-specific hardware support means a game cannot rely on it for "core" physics functionality without severely limiting the potential customer base. Though things are getting better in that respect.

There are some applications. But GPU power are needed for drawing in games. Physical problems in KSP are also such that massive parallelization is not possible or practical. There is not real need for using GPU. KSP has relatively simple physics and if it was coded well it would be easy to fly constructions with several thousands or parts or have much more accurate orbits and predictions, possibility to have some controls on ships without focus etc. It would be much easier to program it well to utilize few CPU cores than program it well to utilize hundreds of GPU cores. In any case Squad should hire some specialists and I do not see it realistic expectation (as economic point of view).

[Red Iron Crown]

Squad's not going to code an engine from scratch for KSP, Hannu2, which is what you're describing. Certainly not for the current game, and likely not for any subsequent ones. Game engines are a whole other level of complexity, and well beyond a team the size of Squad's.

[Hannu2]

Physics of KSP would not be beyond small team, if there were even one physicist (or even student) with some programming experience. I am not sure, but it is hard to believe that it would be impossible to calculate physics with own code and use Unity just rendering things, handle UI etc. So that you just tell Unity that ship X is in place Y and have attitude Z. Rendering is the hard thing in KSP, not physics.

But of course I understand that Squad does not have interest in that. Also huge majority of players are not interested. Probably it would not be economically reasonable. Only hope is that somebody would make some kind of hybrid between KSP and Orbiter which do not even want to be topseller. It could be graphically very primitive but technically complex intended for engineers, scientists or students of such things.

I discussed at general level why there are so few applications (both games and real world things) where GPUs are used in physical simulations. Only few physical problems are well suitable for such level of parallelization with so many restrictions. Some people look just numbers of salesmen and believe that GPUs have some kind of magic tricks which will make everything better.

[Red Iron Crown]

4 hours ago, Hannu2 said:

Physics of KSP would not be beyond small team, if there were even one physicist (or even student) with some programming experience. I am not sure, but it is hard to believe that it would be impossible to calculate physics with own code and use Unity just rendering things, handle UI etc. So that you just tell Unity that ship X is in place Y and have attitude Z. Rendering is the hard thing in KSP, not physics.

You drastically underestimate the complexity of the engine. For each part, the forces must be calculated and summed, then applied within the constraints of the joints, and forces are transferred to other parts further conflating the problem. Collision checks must be done and effects applied, again within the joint constraints and transferring forces. All while keeping performance acceptable. This is not a task for one or two people with "some programming experience", game engines take teams of dozens of experienced coders to produce.

It is *not* a case of "just tell Unity that ship X is in place Y and have attitude Z", that is what happens during the on rails physics currently.

Quote

I discussed at general level why there are so few applications (both games and real world things) where GPUs are used in physical simulations. Only few physical problems are well suitable for such level of parallelization with so many restrictions. Some people look just numbers of salesmen and believe that GPUs have some kind of magic tricks which will make everything better.

Definitely agree here, massively parallel processing isn't some magic bullet appropriate for all problems; it's really only suitable for embarrassingly parallel tasks.

[Hannu2]

11 minutes ago, Red Iron Crown said:

You drastically underestimate the complexity of the engine. For each part, the forces must be calculated and summed, then applied within the constraints of the joints, and forces are transferred to other parts further conflating the problem. Collision checks must be done and effects applied, again within the joint constraints and transferring forces. All while keeping performance acceptable. This is not a task for one or two people with "some programming experience", game engines take teams of dozens of experienced coders to produce.

It is *not* a case of "just tell Unity that ship X is in place Y and have attitude Z", that is what happens during the on rails physics currently.

Definitely agree here, massively parallel processing isn't some magic bullet appropriate for all problems; it's really only suitable for embarrassingly parallel tasks.

I do not underestimate. All interactions you mentioned are simple (from my point of view, I have made some physics modeling for research job and also for hobby by coding things from scratch and using commercial FEM modeling softwares) and number of interactions are very small (typically only few joints between neighbor parts, no long range interactions at all). Parts in KSP are solid rigid things which moves mostly in vacuum. Atmosphere is also modeled by quite simple way. Collision models are relatively simple and collision physics has not to be realistic if it is somewhat believable and good looking. I can not see that complexity. It may be complex for somebody without education and experience of physical models but certainly this kind of model does not need an army of very highly educated experts and years of developing time. One interested student would be enough.

Typically unlinear and soft things are complex in games. Models of elastic living creatures or other soft things are very hard to code so that they even look good. Even movie industry can do it with very limited way in spite of megabudgets and server farms (animation characters looks as animation characters and do not even try to be humans). Other difficult physical thing is fluids and interactions between fluids and soft things (clothes, hairs, smoke). But KSP does not even try to model any of them. Aerodynamic models and atmospheric effects are very simple and spaceflight is moving of rigid bodies in vacuum under simple interactions. There are of course much more examples of difficult models in research, but they are not related to games.

[John FX]

16 hours ago, cantab said:

I'm pretty sure that's incorrect. Remember that nVidia's early "Tesla" physics acceleration cards didn't have a display output at all. I'm 99% certain that modern GPUs are capable of processing data and sending results back to the CPU.

The reason I believe that GPU-accelerated physics is mainly seen for graphical shinies is that limited and vendor-specific hardware support means a game cannot rely on it for "core" physics functionality without severely limiting the potential customer base. Though things are getting better in that respect.

If the GPU can`t do calculations and pass back results then CUDA would not work. I currently rely heavily on being able to pass data to and results from my GPU for video effects.

This is an Nvidia feature though and whether this can be done with other cards is something I don`t know.

It`s rather a moot point if you can`t access those features through Unity anyway.