Why Unity?

[John FX]

If performance in Unity is drastically affected by part count then the obvious solution is to find some way to reduce part count while not affecting gameplay.

Selective welding seems the best way forward. Myself I hate the phantom forces that make larger space stations attempt to rip themselves apart. I would much rather have a station that was mostly solid. It would remove a great portion of the part count hit when building stations. There is no need for them to remain floppy, they just sit there in space essentially doing nothing.

I remember floppy rockets and the sheer amount of struts needed to fly anything larger than a few parts, that was not `fun`.

In a similar way, high part count craft are not `fun` to fly, they are a pain due to low framerates. Myself I would weld anything larger than 2.5M, or anything attached to 2.5M parts or larger.

[jrodriguez]

On 2017-5-8 at 2:30 AM, Red Iron Crown said:

Do any of the modern game engines use doubles for their physics calcs? I suspect not but don't really know.

Wow. I'd love to see Unity using Doubles instead of Float. Physics range extended up to the mun

[softweir]

17 hours ago, Xavven said:

I thought that KSP's physics calculations were CPU intensive, whereas drawing more polygons with higher textures, better lighting, and volumetric clouds, etc. are more GPU intensive.

*snip*

Up to a point. However, the CPU has to squirt the drawing data across to the GPU, and is normally responsible for optimisations such as hidden-object culling (ie, half the Kerbals are out of frame so no need to render them). In addition, when algorithmic scenery is being generated (most scenery is KSP is generated by algorithms) then the CPU has to run those algorithms. What the GPU does is actually draw everything thrown at it by the CPU - which is a huge job, and the reason GPUs now have many more transistors than CPUs!

In theory, it would be possible for a GPU to algorithmically generate a lot of scenery. However in practice we come up against the huge divide between Nvidia, Intel and AMD hardware. The different manufacturers use different systems for getting "code" across to the GPUs, and there are huge differences in numerical precision, rounding and other details that can cause bizarre differences in the final output. While there are reasonably consistent standards for rendering graphics across platforms, non-graphic calculations like algorithmic scenery generation are excessively non-standard. In order to get that to work, developers would have to write a complete new rendering system for each GPU line as well as a fallback CPU-based scenery rendering system to cope with all the cards that are from other manufacturers or are too old to do the job. This is beyond almost every developer, and certainly beyond Squad!

[Fearless Son]

On 5/9/2017 at 4:07 PM, Shadowmage said:

That would be my preferred alternative to floppy rockets.  It makes sense for there to be joints between docking ports for example.  Less so for decouplers (as those are quite rigidly joined until the explosive bolts are fired).  Even just removing the joints between stacked tanks (and the tanks and back-side of the docking port/decoupler) would go a long way to improving the situation from my viewpoint.  But I've never considered the floppy-rockets to be a 'problem that needs to be solved', more of just a bunch of extra steps I need to take to make my rockets do things that they logically shouldn't.  Others have differing views on this.

I feel like the auto-strut feature has actually resolved this pretty handily.  I mean, I think it is part of the intended gameplay design that rockets should be delicate in some ways, players should have to think about the balance of different forces on different parts of the rocket and weigh the benefits of strength/weight requirements of various pieces on various missions.  That said, rockets should not be built out of matchsticks either, and a little forethought on the part of the player during the design phase should be able to overcome these issues.  Manually placed struts are one of the ways this can be resolved, but the auto-struts are a more subtle way of doing it.  They are there if a player needs to use them, but the point is that a player still has to think about how to use them if they do.

I tend to think that kind of consideration is part of the fun, but as fun is subjective your mileage might very.  

[Fearless Son]

On 5/10/2017 at 2:21 AM, John FX said:

If performance in Unity is drastically affected by part count then the obvious solution is to find some way to reduce part count while not affecting gameplay.

Selective welding seems the best way forward. Myself I hate the phantom forces that make larger space stations attempt to rip themselves apart. I would much rather have a station that was mostly solid. It would remove a great portion of the part count hit when building stations. There is no need for them to remain floppy, they just sit there in space essentially doing nothing.

I remember floppy rockets and the sheer amount of struts needed to fly anything larger than a few parts, that was not `fun`.

In a similar way, high part count craft are not `fun` to fly, they are a pain due to low framerates. Myself I would weld anything larger than 2.5M, or anything attached to 2.5M parts or larger.

That is actually something a patch last year handled pretty neatly, by spinning the physics calculations for separate ships out to separate threads.  The total part limit per thread might still be an issue, but two three-hundred part ships in an rendezvous will calculate like two three-hundred part ships, as opposed to one six-hundred part ship which is what it was effectively doing before.  So long as you have multiple core CPUs (as most computers these days do) you have to try a lot harder to drag down that physics performance now than you used to.  

Fun fact: middlewear physics packages like Havok and PhysX are already heavily code optimized, and I speak from the experience of someone who did professional performance testing on a game that used one of those regularly.  So long as you keep the physics objects under a budget, they run incredibly quickly.  Unfortunately, anything that allows users to arbitrarily add things to the simulation is going to go over its nominal CPU budget at some point.  As being able to add objects in various configurations and quantities within the simulation is pretty core to the KSP experience, I cannot see this changing any time soon.  

[DrLicor]

@Fearless Son, about the PhysX thingy, I would like to refer you to this thread.   
 

 

[John FX]

9 hours ago, Fearless Son said:

That is actually something a patch last year handled pretty neatly, by spinning the physics calculations for separate ships out to separate threads.  The total part limit per thread might still be an issue, but two three-hundred part ships in an rendezvous will calculate like two three-hundred part ships, as opposed to one six-hundred part ship which is what it was effectively doing before.  So long as you have multiple core CPUs (as most computers these days do) you have to try a lot harder to drag down that physics performance now than you used to.  

Fun fact: middlewear physics packages like Havok and PhysX are already heavily code optimized, and I speak from the experience of someone who did professional performance testing on a game that used one of those regularly.  So long as you keep the physics objects under a budget, they run incredibly quickly.  Unfortunately, anything that allows users to arbitrarily add things to the simulation is going to go over its nominal CPU budget at some point.  As being able to add objects in various configurations and quantities within the simulation is pretty core to the KSP experience, I cannot see this changing any time soon.  

Rather good explanation of why there will always be a CPU bottleneck for high part count craft, even though two high part craft would not slow down a machine with multiple cores much more than one. Reinforces my idea that on the fly `welding` of certain parts would be a good performance boost. You would only need to unweld if forces moved beyond a certain threshold, lithobraking for example. Even then, if the forces were above a certain threshold a more simple explosion scenario could play out. Only in the middle range of forces would there be an impact, then wobbling, which would be unavoidable physics calculations on the whole craft.