[WIP] Radioactivity - test release 0.1.1 (Sept 7, 2016)

[TiktaalikDreaming]

6 hours ago, Buster Charlie said:

I'm down for banana dosage schemes, call them dB, for deciBananas 

1 Deca Banana = 1 micro Sievert, unfortunately, Deca is Capital, as deci, being 0.1 is the lower case.  So, you need 100dB for a microSievert.

Yay metric.  although I don't think banana is the preferred SI unit normally, it does seem remarkably Kerbal.  The numbers involved for "banana scale" will tend towards different prefixes than Deca though.  EG: Short term exposure with likely health issues will be around the 4 Mega Banana (MB).  Although only 1MB per year is needed for (statistically) detectable increased cancer risk.  KiloBananas (kB) might be around the measurement needed.

One thing I do know;

The bananas will be green, surely.

[Nertea]

I kinda think I'd rather do SI units than bananas, but it would be (relatively) trivial to make that a flag in the settings, and it's amusing enough that maybe it's a thing I could justify!

Throw in an MM patch to make Banana For Scale a radiation emitter and you're good :P.

14 minutes ago, aeroeng14 said:

This really seems promising, the first true concrete steps toward a "simulated" radiation mechanic. I do appreciate and fully support the simplifications and balance you're making and think they will be totally justified given KSP, the user base, and what's fun. Really wish I could contribute in someway to the development, but my modding skills are non-existent. Perhaps in the testing phase. I'll be keeping a watch on this for sure and keep trucking Nertea! 

I'm glad you like the sound of this. I hope it gets to the point where it's nice and stable, right now there are still many issues to fix up. There was some hope for useable development versions by the end of the week, but that ship seems to have sailed. 

[RedParadize]

If radiation turn kerbals to yellow, then I am for the banana mesurement !

[Buster Charlie]

42 minutes ago, TiktaalikDreaming said:

1 Deca Banana = 1 micro Sievert, unfortunately, Deca is Capital, as deci, being 0.1 is the lower case.  So, you need 100dB for a microSievert.

Yay metric.  although I don't think banana is the preferred SI unit normally, it does seem remarkably Kerbal.  The numbers involved for "banana scale" will tend towards different prefixes than Deca though.  EG: Short term exposure with likely health issues will be around the 4 Mega Banana (MB).  Although only 1MB per year is needed for (statistically) detectable increased cancer risk.  KiloBananas (kB) might be around the measurement needed.

One thing I do know;

The bananas will be green, surely.

Oh it's always the power of 10 prefixes that mess me up. Ah well you get the idea.

 

[Deimos Rast]

ya'll are talking about deca banana's and I just want a Kerbal Hulk.

Or is it too soon to hope for?

[123nick]

will raycasting be only too the center of a part? because, what if you had a gigantic pod, and a nuclear engine with a small fuel tank between them both. sureley, the edges of the pod would get some radiaton, right?

[Nertea]

On 3/4/2016 at 2:26 PM, 123nick said:

will raycasting be only too the center of a part? because, what if you had a gigantic pod, and a nuclear engine with a small fuel tank between them both. sureley, the edges of the pod would get some radiaton, right?

There are necessary simplifications to reduce the computational load. Simulating many points in order to simulate a volume rapidly becomes computationally nasty.

[Varses]

Hope you're still working on this as it's exactly the kind of mod I was looking for (as far as the planned features).

I know nothing about modding KSP but I was thinking that it might be possible to create a 'radioactive fallout' system that would increase the background radiation of a region based on how heavily you use/crash nuclear engines there. You could divide the planet into regions (a la the Kethane mod) with each region having a quantity of a 'radioactivity' resource. Using nuclear engines would act like drills in reverse, adding the radioactivity resource to the region instead of removing it. The more resource in the area, the higher the background radiation. Crashing nuclear objects into the ground (engines, RTGs, resource tanks) would also increase the radiation by a set amount. To reverse this, there could be a part which would take a large amount of energy to clean up the radiation.

Just a thought, though maybe out of the intended scope of this mod. In any case, I hope you keep working on this whatever you end up adding

Edited April 11, 2016 by Varses

[Nertea]

That is about out of scope yes. It would involve quite a bunch of tracking which isn't very interesting. I did want to have rep penalties stuff at some point

And yes, still working on this, but it's strictly a after-1.1-is-stable project. 

[soundnfury]

1 minute ago, Nertea said:

And yes, still working on this

\o/

 

Take all the time you need

[ThatOneBritishGuy...]

Are there plans to use The Solar Cycle Simulator mod for this?

[skykooler]

So, this would create a reason to make long spindly ships - move the radiation source far enough away, and the inverse square law is the best shielding!

[FreeThinker]

4 hours ago, skykooler said:

So, this would create a reason to make long spindly ships - move the radiation source far enough away, and the inverse square law is the best shielding!

Indeed, and also build the ship like a verse triangle , hidding behind a shadow shield. KSPI-E already has radiators shaped for this purpose

[JaredTheDragon]

Computationally and physically, radiation is simply photon emission. So to calculate the mass of these emissions is really straightforward, since it's just the charge field. You don't need to calculate the individual photons (and every computer combined still couldn't do so, anyway), and it doesn't need to be a particle system at all - though to be predictive accurately of course that would be preferable. But unattainable.

Photons fall off inversely proportional to the square of the distance from the source, so it's really easy to crunch.

[Galacticat]

I know it's been a while since anyone's been on this thread, but I was just wondering when you return to this, maybe you could add functionality with Kerbalism's radiation mechanics.

[FreeThinker]

Indeed, it would be great if these mods could somehow be integrated

[ShotgunNinja]

I was thinking about how to speed up or even avoid raycasting altogheter and had an idea, that I figured could be useful to post here.

It looks to me the problem is mostly related to eva kerbals and inter-vessel radiation, as in all other cases the inter-part visibility can be precomputed on vessel change events (eg: staging, docking). So the problem reduce to precomputing a static visibility/opacity function per-part, that can be queried from arbitrary directions. A possible solution is to approximate the visibility function using spherical harmonics:

• on vessel change event:
  • for each part:
    • initialize SH coefficients storage
    • for each other part:
      • project bounding sphere visibility+opacity on the SH coefficients and accumulate them

• on each simulation step, for the active vessel
  • for each kerbal/instrument:
    • initialize total incoming radiation to zero
    • for each radiation emitter:
      • resolve the visibility/transparency using SH
      • use the result to scale emitter radiation, and accumulate that

Total storage for 2nd order SH per-part would be 9 floats. Total computation cost of projection would be relatively high, but only necessary at vessel change events: 11 additions and 24 multiplications for each part pair. Total computation of SH resolution would be relatively low: 10 additions and  22 multiplications per-simulation step for each kerbal/instrument -> radiation emitter pair, in the active vessel.

[Nertea]

On 5/28/2016 at 4:00 AM, ShotgunNinja said:

I was thinking about how to speed up or even avoid raycasting altogheter and had an idea, that I figured could be useful to post here.

It looks to me the problem is mostly related to eva kerbals and inter-vessel radiation, as in all other cases the inter-part visibility can be precomputed on vessel change events (eg: staging, docking). So the problem reduce to precomputing a static visibility/opacity function per-part, that can be queried from arbitrary directions. A possible solution is to approximate the visibility function using spherical harmonics:

• on vessel change event:
  • for each part:
    • initialize SH coefficients storage
    • for each other part:
      • project bounding sphere visibility+opacity on the SH coefficients and accumulate them

• on each simulation step, for the active vessel
  • for each kerbal/instrument:
    • initialize total incoming radiation to zero
    • for each radiation emitter:
      • resolve the visibility/transparency using SH
      • use the result to scale emitter radiation, and accumulate that

Total storage for 2nd order SH per-part would be 9 floats. Total computation cost of projection would be relatively high, but only necessary at vessel change events: 11 additions and 24 multiplications for each part pair. Total computation of SH resolution would be relatively low: 10 additions and  22 multiplications per-simulation step for each kerbal/instrument -> radiation emitter pair, in the active vessel.

So right now the cost isn't too high for the raycast method. Everything is calculated once on vessel changes, and establishes a set of attenuation paths that can be solved easily and cheaply per step. Then the paths get recomputed whenever there is enough positional change between a source/sink pair. 

The problem gets really complex when there are two ships maneuvering near each other, because their attenuation and opacity functions would be both changing constantly due to parts of different density and different angular orientations. At that point I'm not sure how much gain doing something mathematically fancy is going to give. I think that raycasting gives the most general reliable solution.

[ShotgunNinja]

@Nertea Sure, that was just an idea. In your case it can be useful, perhaps, as spherical harmonics are merely an easy and cheap way to encode a low-resolution approximation of a function over the sphere and then to query it. They can be understood in a certain sense as 'very blurry environment cube maps' that can be stored in a bunch of floats. They especially excel in encoding static (or semi-static) visibility information. The code seem complex, but is very simple (hence their use in realtime computer graphics). To give you an example, this is the whole 2nd order SH related code that would be required to store the coefficients, project the visiblity/opacity function on the basis, and then resolve the resulting spherical function on an arbitrary direction (this is c++):

Spoiler

struct sh_coefficients
{
  // project a value into the basis and add it to the coefficients
  void project(float value, const vec3& dir)
  {
  	const float f1 = 0.282095f;
  	const float f2 = 0.488603f;
  	const float f3 = 1.092548f;
  	const float f4 = 0.315392f;
  	const float f5 = 0.546274f;
  
  	L00  += f1 * value;
  	L11  += f2 * value * dir.x;
  	L10  += f2 * value * dir.z;
  	L1_1 += f2 * value * dir.y;
  	L21  += f3 * value * (dir.x * dir.z);
  	L2_1 += f3 * value * (dir.y * dir.z);
  	L2_2 += f3 * value * (dir.x * dir.y);
  	L20  += f4 * value * (3.0f * dir.z * dir.z - 1.0f);
  	L22  += f5 * value * (dir.x * dir.x - dir.y * dir.y);
  }
  
  // resolve the spherical function over a direction
  float resolve(const vec3& dir) const
  {
  	const float c1 = 0.429043f;
  	const float c2 = 0.511664f;
  	const float c3 = 0.743125f;
  	const float c4 = 0.886227f;
  	const float c5 = 0.247708f;  

  	return c1 * L22 * (dir.x * dir.x - dir.y * dir.y) + c3 * L20 * dir.z * dir.z + c4 * L00 - c5 * L20
    		+ 2.0f * c1 * (L2_2 * dir.x * dir.y + L21 * dir.x * dir.z + L2_1 * dir.y * dir.z)
       		+ 2.0f * c2 * (L11 * dir.x + L1_1 * dir.y + L10 * dir.z);
  }    
  
  float L00;
  float L1_1;
  float L10;
  float L11;
  float L2_2;
  float L2_1;
  float L20;
  float L21;
  float L22;
};

 

 

[MarkusA380]

Cool idea! Looking forward to it!

[ThatOneBritishGuy...]

Any recent progress on this Nertea?

[Nertea]

On 8/18/2016 at 0:44 PM, ThatOneBritishGuy... said:

Any recent progress on this Nertea?

I am working on this in parallel with FFT to some extent. I dusted off the code this morning and realized that I hadn't run it since 1.1, so I need to spend some time rejigging things to work in 1.1+.

I'm thinking of trying to release a type of testing build in a week or two with the basic simulation aspect more or less finished. The thing that was last giving me the most grief was getting the simulation reliably working in the VAB, so I might leave that out. 

[Nertea]

Well so I have the following stuff pretty much working now!

• Persistent radiation exposure tracking for kerbals
• Full emitter/sink simulation in both the VAB and flight
• A roster UI that is almost competent
• A overlay UI that is terrible and not very useful
• Functional emitter modules for radioactive engines and radioactive resources
• Functional sink modules for crew containers, generic rad tracking

What still remains:

• Catchup/background processing of radiation exposure
• Shadow shields inside parts
• Redo the overlay UI to be better and more useful
• Many tweaks to exposure and sink functionality
• Emitter modules for other things (NFE reactors)
• Sink modules for probe cores, science instruments
• Placeholder parts for radiation shields, geiger counters

I've also normalized units on Sv for everything. Not the most valid assumption but I have to simplify.

The thing I need to start thinking about is plugging values into things so I can start calibrating stuff for balance. I'd like to open the floor to any input from people here. I've established a few general constants that seem like they will make sense

• Threshold for radiation sickness: 2 Sv total
• Threshold for radiation death: 10 Sv total
• Heal rate for radiation damage on-mission: 0.1 Sv per year
• Heal rate for radiation damage at KSC: 5 Sv per year

Some starter questions:

• What should be the dose rate for an unshielded Kerbal beside a reactor when it's running (like an LV-N)? Should the kerbal die instantly (given death at 10Sv that would be more than 10 Sv/s)
• What does a reasonable ship using this mod look like? Given the limitations of KSP in terms of part rigidity and such, this is important to calibrate the absorptivity of parts
• What kind of mass penalties occur when adding radiation shadow shields?
• What parts have integrated shadow shields?

Lastly, I did make another plugin which is separate from Radioactivity called GlowingReputation, which in a simple aspect supports Radioactivity by introducing reputation penalties for destroying radioactive parts in sensitive environments, and reputation penalties for operating certain engines in sensitive environments. This is almost ready for testing too.

 

[soundnfury]

Nice update, looking forward to this!

2 hours ago, Nertea said:

Some starter questions:

• What should be the dose rate for an unshielded Kerbal beside a reactor when it's running (like an LV-N)? Should the kerbal die instantly (given death at 10Sv that would be more than 10 Sv/s)

I don't think the LV-N should be an insta-kill; it's no Project Pluto.  I'd say something like 30 seconds of direct exposure should cause meaningful damage.  So, a little less than 0.1Sv/s on your scale.

[TiktaalikDreaming]

15 minutes ago, soundnfury said:

Nice update, looking forward to this!

I don't think the LV-N should be an insta-kill; it's no Project Pluto.  I'd say something like 30 seconds of direct exposure should cause meaningful damage.  So, a little less than 0.1Sv/s on your scale.

I'm inclined to agree.  The NERVA style solid core NTRs will usually be "shielded" to reflect neutrons back into the core to reduce required critical mass, if for no other reason.  And if the base NTRs are quick kills, where does that leave options for more lethal engines?  AKA, I'd like to be able to make my open-cycle gas core NTR significantly nastier than stock NTRs.

Once upon a time, I had notes on shadow shielding materials.  I'll see if I can dredge that up.