KSP Weekly: The Neutron Star Merger

[SQUAD]

Welcome to KSP Weekly everyone. This Monday the LIGO and VIRGO collaborations presented groundbreaking observations of an astronomical phenomenon which has never been seen before. This phenomenon was the merging of two neutron stars a 130 million light years away. What makes this discovery particularly exciting, is that this is the first ever detection of gravitational waves from inspiraling neutron stars, and the same event has been observed with telescopes in all areas of the electromagnetic spectrum.

It all began around two months ago (On August 17, 2017), when LIGO’s interferometers identified a clear gravitational wave signal that lasted about a hundred seconds, which by the way is also the longest signal detected until now, and was consistent with the theoretical prediction for the signal that would come from two merging neutron stars. They immediately alerted observatories around the world and in a matter of hours the event had been located. The fact that the event’s location was located in the immensity of space is very impressive by itself, and was only accomplished thanks to the collaboration and contribution from over 70 observatories around the globe. The way the merging was located is quite interesting too. Seven seconds after LIGO’s first detection, NASA’s Fermi Gamma-Ray Telescope identified a burst of gamma rays - which have been thought to come from neutron star mergers for a long time, but the evidence has been lacking until now. To link the gamma-ray burst with the detected gravitational waves, scientists needed to pinpoint where in the sky this neutron star merger had occurred. Neutron stars emit light when they smash together and continue emitting electromagnetic radiation afterwards, so scientists knew what to look for. Using the Fermi Gamma-Ray Telescope, the Fermi team identified a large patch of the sky, and with further data from the European Space Agency’s Integral Gamma-Ray Satellite, they were able to narrow down the gravitational waves detected by LIGO even further. This allowed them to identify two long strips in the sky, one of which overlapped with the existing search area. Additionally, the VIRGO gravitational wave detector, located in Italy, was online at the time and it should have been able to detect these gravitational waves but yet it detected almost nothing, which indicated that the gravitational waves must be have been coming from one of that detector’s blind spots. This helped to further narrow the search area, where around fifty galaxies were identified to be studied with optical telescopes. Eleven hours after the initial detection, astronomers located a bright spot in the Galaxy NGC 4993. The colour and brightness of that bright spot changed in the aftermath of the collision. Click here to see an awesome animation of a neutron star merger.

Neutron stars are the collapsed core of large stars (between 10 and 29 solar masses) that have gone supernova and combined with the gravitational collapse, compresses the core past the white dwarf star density to that of atomic nuclei. If the remnant has a mass greater than about 3 solar masses, the neutron star continues collapsing to form a black hole, but if those cores are a bit smaller, then they get squeezed still and so electrons merge with protons to form neutrons and neutrinos and turn to the smallest and densest stars known to exist. They are supported against further collapse by neutron degeneracy pressure, a phenomenon described by the Pauli Exclusion Principle. If you have two neutron stars orbiting each other, they emit some of their energy as gravitational waves and as they do that, they lose energy while spiraling close to each other. When they get really close to a few hundred kilometers apart, the gravitational waves become intense, allowing us to detect them hundreds of millions of light years away.

The collision of neutron stars creates a kilonova, which spews debris out into space. This debris emits light and allows scientists to observe what’s been created. Through these new observations with light telescopes, scientists detected heavy elements like gold, lead and platinum, which helps us to understand where some of the heavy elements in our Universe come from. This is a huge discovery and the fact that we live in an era in which we are able to detect, pinpoint and observe events like a neutron star merger is just incredible. What an exciting time to live. Sorry for this long introduction, let’s move on and talk about KSP development.

[Development news start here]

The team continues with the development of the Making History Expansion. This week, some developers worked on the Mission App; a display where the player will see all the objectives and their criteria along with a status (Complete, Incomplete, In-progress, etc) while playing a Mission. They created new UI prefabs, set up some code and added functionality to display the Body Node info from the Mission Builder’s canvas in the Missions App while in the Flight Scene. Similarly, some of the developers worked on the implementation of ‘tooltips’ for the Mission Builder scene and its UI, as well as for the SAP parameters.  

Additionally, the team worked on the design and implementation of an algorithm that maps the program flow of the Nodes to a list format that will then be rendered to the multiple places where a list of objectives is used, so that it can give a visual indication of paths through the map.

This week also saw some improvements to the Orbit Gizmo, which, as we have explained in previous issues, will allow creators to set orbits for vessels as they see fit. Sounds simple, right? Well, there is a lot of math required to identify an object’s orbit and its specific position in that orbit. The game’s code uses basically three parameters to identify this: 1) The orbital period, which is the time a given object takes to complete one orbit around another object, let’s say a planet. 2) The epoch, which is a moment in time used as a reference point for an object in an elliptical orbit. 3) And last, but not least, the Mean Anomaly, which is an angle used in calculating the position of a body in an orbit - it is the angular distance from the pericenter which a fictitious body would have if it moved in a circular orbit, with constant speed, in the same orbital period as the actual body in its elliptical orbit. We can determine the position of an object in an orbit by calculating the mean anomaly at epoch - which is directly influenced by the orbital period - using basic arithmetic, but as we like to keep things simple, by setting the epoch at zero, the only parameter a player will need to set is the angle (mean anomaly) at which he would like to place a vessel. One of the developers has been playing around with the Orbit Gizmo in the Mission Builder and this clip showcases the same orbit for 6 asteroids generated an hour apart from each other (take into account that Kerbin has 6-hour-days). This is just an example of the crazy things you’ll be able to do with this tool.

The team also finished testing another batch of already implemented nodes for the Mission Builder, so let’s go into further detail (as always remember that this is still subject to changes).

• Escape SOI Node (Location type): This node will allow you to set the objective of leaving the Sphere of Influence of a particular celestial body and travelling to another one.
  
• Vessel Splashed Node (Location type): This node will allow you to set the objective of splashing down into a body of water at specific coordinates on a planet.
  
• Flight Elapsed Time Node (Logic type): This node will allow you to measure flight time within a Mission, after a vessel has launched and do something with it. 
  
• Mission Time Node (Logic type): Unlike the Flight Elapsed Time Node, this node will allow you to measure the overall duration of a mission.
  
• Vessel Mass Node (Logic type): This node will allow you to set the mass for vessels as a condition in a Mission.
  
• Part Explode Node (Action type): This node will allow you set an explosion event for a part and trigger it at a given moment during a mission. There is a different Node for whole vessels by the way.
  

The art team is currently busy working on the geometry and texture of a new liquid-fuel cryogenic rocket engine, specially designed for large vessels and inspired on NASA’s J2 Engine, which you probably know from the Saturn V and Saturn IB rockets. It is still early for sneak peeks, but we’ll show it to you soon. The team is also working on new textures and configurations for the 1.875m and the 5m fairings.

In other news, we keep on getting newer and better builds of KSP on consoles from our friends at Blitworks. Some noteworthy fixes in the last builds include a bug that caused a severe performance drop for a brief period  when players entered the Tracking Station from the Launchpad and then returned to the Space Center. Another issue addressed was triggered when a player attempted to delete a save from the Resume Game Menu, instead of deleting the save, accepting the deletion would open the save file instead. A issue regarding the controller inputs was fixed too. This one was triggered when attempting to edit parts on a craft; with the new mapping the D-Pad left and right allows the player to select the parts to edit via a highlight. The top face button (PS4 triangle or XB Y) can then be used to scroll through the editor gizmos. Attempting to cancel this operation failed and left some buttons unresponsive. Luckily, you won’t have to worry about these and other issues thanks to the external testing team, our own QA team and Blitworks.

Finally, the team started to work on upgrading the project to Unity 2017.1. This implementation will be included in the upcoming 1.4 Update of KSP.

That’s it for this week. Be sure to join us on our official forums, and don’t forget to follow us on Twitter and Facebook. Stay tuned for more exciting and upcoming news and development updates!

Happy launchings!

PD: Do you want to help the victims of the Earthquakes in Mexico? You can do so by donating to any of these non-profit institutions. Your contributions will make a huge difference:

• Mexican Red Cross
  
• Habitat for Humanity
  
• Ambulante
  
• Topos Rescue Brigades
  
• UNICEF
  

[Just Jim]

8 minutes ago, SQUAD said:

This implementation will be included in the upcoming 1.4 Update of KSP.

1.4???  

Edited October 20, 2017 by Just Jim

[Tyko]

24 minutes ago, SQUAD said:

Finally, the team started to work on upgrading the project to Unity 2017.1. This implementation will be included in the upcoming 1.4 Update of KSP.

Wow, great news that the next release is already in the works. Despite the earthquake and other issues Squad keeps motoring along

Is there a high-level overview of the expected improvements Unity 2017.1 will provide?

Edited October 20, 2017 by Tyko

[0111narwhalz]

31 minutes ago, SQUAD said:

The game’s code uses basically three parameters to identify this:

What about eccentricity and inclination (plus longitude of ascending node)?

[Deddly]

I really love the astronomy news in these weeklies. It's always a highlight for me.

[NoMrBond]

24 minutes ago, Tyko said:

Is there a high-level overview of the expected improvements Unity 2017.1 will provide?

KSP is (currently) running on Unity 5.4 (.0p4 I think), so there's all the updates for 5.5 and 5.6 as well as what 2017.1 is bringing (which is a lot)

Basic summary would be major particle system overhaul and PhysX (to 3.3.3) update (added in u5.5), Vulkan/Metal support + script/shader based particle systems (added in u5.6)

I think the big one might be the C#v6/.NET4.5 runtime support added in 2017.1 though, that's a major update from the kinda/sorta C#v3/.NET3.5 support

It'll be interesting to see which new features will be flexed/implemented during the upgrade from 5.4 to 2017.1

[Edit] Maybe this will also be the point where KSP's assets are moved into assetBundles to take advantage of dynamic loading/unloading?

Edited October 20, 2017 by NoMrBond

[Tyko]

2 minutes ago, NoMrBond said:

KSP is (currently) running on Unity 5.4 (.0p4 I think), so there's all the updates for 5.5 and 5.6 as well as what 2017.1 is bringing (which is a lot)

Basic summary would be major particle system overhaul and PhysX (to 3.3.3) update (added in u5.5), Vulkan/Metal support + script/shader based particle systems (added in u5.6)

I think the big one might be the C#v6/.NET4.5 runtime support added in 2017.1 though, that's a major update from the kinda/sorta C#v3/.NET3.5 support

It'll be interesting to see which new features will be flexed/implemented during the upgrade from 5.4 to 2017.1

Thanks for that info...I'm not a game coder and was hoping for a bit more information about "what differences will a player see in KSP after the update"

[passinglurker]

3 hours ago, SQUAD said:

The art team is currently busy working on the geometry and texture of a new liquid-fuel cryogenic rocket engine, specially designed for large vessels and inspired on NASA’s J2 Engine

So you are makeing the engine the stock rhino engine was based on? Can you just replace the rhino engine then?

3 hours ago, SQUAD said:

Finally, the team started to work on upgrading the project to Unity 2017.1. This implementation will be included in the upcoming 1.4 Update of KSP

Sigh yet another code base overhaul... It amazes me to no end how squad has the resources to completely rewrite the game every major update yet they can't spare resources for comprehensive art and career mode game play polish. 

Edit: It's too soon to judge excuse my salt.

Edited October 20, 2017 by passinglurker

[Deddly]

@passinglurker I guess it's a question of what they choose to prioritise. Different people have widely polarised views as to what they view as important. I get the impression that the graphics are very important to you and others, but for many people, an engine update is much more interesting. It's a simple matter of differing priorities.

[MrChumley]

Fun tidbits:

Galaxy NGC 4993 is 40 Megaparsecs (~160 million light years) away... so that gravitational wave has been traveling towards us for a very long time.

From

Unity 2017.1.0f3 Release Notes

Added:

Custom vertex streams:

And my personal favorite;

New Donut emission particle:

now im hungry

Edited October 20, 2017 by MrChumley

[CobaltWolf]

1 minute ago, Deddly said:

@passinglurker I guess it's a question of what they choose to prioritise. Different people have widely polarised views as to what they view as important. I get the impression that the graphics are very important to you and others, but for many people, an engine update is much more interesting. It's a simple matter of differing priorities.

What does the engine update change? What differences would it make that your average player would notice? (Not trying to start a commotion, I genuinely don't know. More efficient maybe?)

[NoMrBond]

Just now, Tyko said:

Thanks for that info...I'm not a game coder and was hoping for a bit more information about "what differences will a player see in KSP after the update"

The C#/.NET update should make the game run better (accumulated runtime/programming improvements since C#v3 in 2008)

The other graphical stuff should make particle systems (engine exhausts / rocket trails) look better

[Deddly]

Just now, CobaltWolf said:

What does the engine update change? What differences would it make that your average player would notice? (Not trying to start a commotion, I genuinely don't know. More efficient maybe?)

I don't know, either. I'm looking forward to finding out

[CobaltWolf]

6 minutes ago, NoMrBond said:

The C#/.NET update should make the game run better (accumulated runtime/programming improvements since C#v3 in 2008)

The other graphical stuff should make particle systems (engine exhausts / rocket trails) look better

I'm not so sure about that. KSP still uses the horrible legacy particle systems. While I'd eagerly welcome better particles for stuff like exhausts, there isn't exactly a precedent for updating them since the particles we do have were deprecated many releases ago and haven't changed.

EDIT: Or, maybe another way of looking at it - we were supposed to get the new Unity 5 shaders in 1.1 and still don't have those either. I'm not talking about revamped parts, I'm saying a new set of KSP shaders based on the Unity 5 PBR shader, which are comparable if not easier to create than making the various particle effects in KSP work with the updated particle systems.

6 minutes ago, Deddly said:

I don't know, either. I'm looking forward to finding out

Fair enough.

Edited October 20, 2017 by CobaltWolf

[NoMrBond]

Just now, CobaltWolf said:

I'm not so sure about that. KSP still uses the horrible legacy particle systems. While I'd eagerly welcome better particles for stuff like exhausts, there isn't exactly a precedent for updating them since the particles we do have were deprecated many releases ago and haven't changed.

True, should != will

I'm simply hoping all the new features will get implemented, right to the hilt

[CobaltWolf]

1 minute ago, NoMrBond said:

True, should != will

I'm simply hoping all the new features will get implemented, right to the hilt

Of course, that's all we can hope for.

And of course, the engine update probably has nothing to do with the art - programmers and artists are generally separate people, after all. You can't tell your programmers to make art and expect good results, and vice versa. So even if Squad were to focus on the game's art, this update would still likely happen since the programmers need stuff to do!

Edited October 20, 2017 by CobaltWolf

[passinglurker]

6 minutes ago, Deddly said:

@passinglurker I guess it's a question of what they choose to prioritise. Different people have widely polarised views as to what they view as important. I get the impression that the graphics are very important to you and others, but for many people, an engine update is much more interesting. It's a simple matter of differing priorities.

I never prioritized graphics I prioritized consistency without regression. 

I'll concede though that it's too early to judge but given the pattern established so far I'm choosing to withhold my hype. I'll buy a ticket on the patience ferry for this one.

[Deddly]

6 minutes ago, CobaltWolf said:

And of course, the engine update probably has nothing to do with the art - programmers and artists are generally separate people, after all. You can't tell your programmers to make art and expect good results, and vice versa. So even if Squad were to focus on the game's art, this update would still likely happen since the programmers need stuff to do!

There are surprisingly few people who think of this. Thanks for pointing it out, I think it's very important.

[stibbons]

17 minutes ago, CobaltWolf said:

What does the engine update change? What differences would it make that your average player would notice? (Not trying to start a commotion, I genuinely don't know. More efficient maybe?)

The bump in the mono runtime does indeed bring better performance and improved garbage collection (I never notice it, but hopefully this will improve frame "stutter"). Modders will also almost certainly appreciate the new language features and APIs - I know I'm looking forward to that.

[JPLRepo]

43 minutes ago, 0111narwhalz said:

What about eccentricity and inclination (plus longitude of ascending node)?

They are all available to the mission builder when defining Orbits on a node as part of the requirements to be met.

[Deddly]

9 minutes ago, passinglurker said:

I never prioritized graphics I prioritized consistency without regression.

Sorry if I misrepresented you. I have only seen you post about the art quality. But of course, most of us appreciate quality in all areas of the game.

[JPLRepo]

36 minutes ago, passinglurker said:

<snip>

Sigh yet another code base overhaul... It amazes me to no end how squad has the resources to completely rewrite the game every major update yet they can't spare resources for comprehensive art and career mode game play polish.

Code base updates are required in order to keep the game on a supported platform. As the game engine is upgraded, so must the game move to these upgrades.
Failing to do so means the game will be on an unsupported platform. Which is hard to maintain and update. and... as others have suggested, upgrading brings lots of new and improved features that can be exploited, and not to forget bug fixes in the core platform (Unity).

[Deddly]

Do we know if the Unity upgrades could do anything about the wheels and landing gear so we don't have to rely on autostruts?

[Shadowmage]

31 minutes ago, CobaltWolf said:

EDIT: Or, maybe another way of looking at it - we were supposed to get the new Unity 5 shaders in 1.1 and still don't have those either. I'm not talking about revamped parts, I'm saying a new set of KSP shaders based on the Unity 5 PBR shader, which are comparable if not easier to create than making the various particle effects in KSP work with the updated particle systems.

Having recently tackled this problem personally (and actually got it working in KSP), I can say the chances of KSP adapting the new shaders are low.  The problems can be solved, and the shaders can work in KSP (with a bit of hacking) -- but all that means is that -every single existing stock art asset has to be redone- as the texture setup used by the PBR shader is completely different than the legacy diff/spec setup.  You can't simply re-use the existing textures as the channel mappings are all wrong; there is also no simple ability to convert between legacy diff/spec textures and PBR textures -- each set would have to be manually reworked, and even with access to the original layered source files it would be a major undertaking.  Combine that with the existing KSP art-style.... it really doesn't make any sense for stock to move to the new shader (might actually be harder to do the existing art style under the new shader setup).

Would I love it if it were supported?  Absolutely.   But I don't personally think it is in SQUAD's plans (or really even in their best interest); there are more productive ways to spend their time than redoing already functional art.  (I guess technically there is nothing stopping them from getting the shaders -working- in KSP; just because they are working/included doesn't mean they need to use them).

 

@CobaltWolf  -- if you are really interested in using PBR shaders in KSP, stop by the SSTU thread.  I'll likely have them publicly available soon as a stand-alone mod/plugin.

Pics in spoiler so as to not derail the thread any further...:

Spoiler

Relevant to the conversation, a bit -- Unity Standard shader at work in KSP (texturing WIP....).  They really can make a substantial difference in the look of the parts with the subtle reflections and ambient light handling.

 

I am personally interested if there are any wheel-physics fixes included with the updated Unity version.  Namely the ability to arbitrarily rotate a WheelCollider relative to its RigidBody -- this was the single largest driving reason why I developed KSPWheel (U5 wheel colliders must be aligned with the axis of the RigidBody... and thus with the axis of the Part; makes so many things impossible to do in KSP with the U5 wheels).

[DMagic]

1 hour ago, CobaltWolf said:

I'm not so sure about that. KSP still uses the horrible legacy particle systems.

Do the Part Tools not support the new (not new at all ) Particle Systems components? That's horrible if you still have to use those clunky old Particle Emitter / Animator / Renderer components.

I suppose it's probably not that difficult to come up with a way to just export Particle System asset bundles and plug them into the parts at runtime, it's just a lot more complicated than it should be. The same presumably goes for PBR shaders.

1 hour ago, NoMrBond said:

I think the big one might be the C#v6/.NET4.5 runtime support added in 2017.1 though, that's a major update from the kinda/sorta C#v3/.NET3.5 support

But I don't think it supports that by default. Right now .NET4.5 support is an option in the player settings (and it's marked "experimental"), so I'm not sure if it's something that KSP or mods would actually be able to use.

1 hour ago, Tyko said:

Is there a high-level overview of the expected improvements Unity 2017.1 will provide?

I think the change from Unity 5 to 2017 is much less significant than than the change from 4 to 5. And the update from KSP 1.0 to 1.1 (where they switched to Unity 5), and all the changes that entailed, wasn't actually all related to Unity 5. The new UI probably took up an enormous amount of development time (recreating the same UI in a different system is really boring, tedious work) and it didn't actually have anything to do with Unity 5. So I wouldn't expect to have an excessively long update time followed by another broken release like we did with KSP 1.1.

Edited October 20, 2017 by DMagic