Thermal mechanics and physicsSignificance

[allmhuran]

Has there been any definitive post describing how the thermal system works with a part that has its physics significance set to 1 ("no physics")? I recall that these initially had issues with thermo, blowing up very quickly (in fact, people were using cubic octagonal struts sacrificially like heatshields). Will the part behave thermodynamically according to all the normal config settings (mass, thermal multiplier, etc)? Or do they do... erm... "weird stuff"?

Edited September 16, 2015 by allmhuran

[Gaarst]

Their mass is added to their parent part, but the drag is still applied at the physicsless part I think.

[NathanKell]

thermo treats them no differently from any other part.

[allmhuran]

Excellent! Cheers Nathan.

The reason for the question might be interesting to some people, so I will include some explanation: Parts with very low mass have extremely weird joints. They don't break exactly. Rather, parts attached to them tend to "slide around" on the joint, on all three axes. An easy way to see this is to create a nice stable "platform" ship with a wide, heavy base and a vertical mast. To the top of the mast, attach a low mass (< 0.01, the lower the better) part with normal physics (physicsSignificance=-1) at, say, a 45 degree angle from vertical. Just edit any part config temporarily to do this. Then to that attach another girder with a weight on the end, so that the weight is held out away from the mast.

When you launch this craft, the angled girder and the weight will start to "float" around. It slide and bounce around, clipping into and out of the low mass part. It's not subtle, I've seen things move meters in this manner, but without actually breaking. It's super, super weird.

But if you change the physics significance of the low mass part to 1, this doesn't happen anymore. The joint becomes rock solid, just like any other "normal" joint.

This may be of great interest to people working with infernal robotics. IR does not work well with heavy parts due to some issue with the type of unity joint they have to use to be "dynamic". So you might want to make very low mass parts to avoid the IR bounciness. But if you do this, then you run into the native KSP problem of low mass joints having these weird, slidey-aroundy connections, defeating the purpose of dropping the part mass.

I have spent dozens of hours with my mechs trying to deal with this problem. I thought it was all an IR issue, only tonight did I discover that this is a problem with stock KSP parts that have very low mass.

[allmhuran]

 

On 9/15/2015 at 2:05 AM, NathanKell said:

thermo treats them no differently from any other part.

 

Sorry to necro this but there's definitely a thermo bug with physicsless parts if this is still supposed to be the case. Observe the following gfy.

For the first half of the gfy the large plate has physicsSiginficance=1. Heat is transferred to the parent girder segment at an alarming rate, even when the rocket engines are at minimal thrust.

For the second half, the physicsSignificance line is commented out. No other changes were made. The behaviour is completely different - in fact, I can put the rockets to full throttle and still only overheat very slowly, and the girder doesn't get overheated superfast. 

It looks like conductivity is ignored for phyiscsless parts, with all heat (and perhaps even "extra" heat) being transferred to the parent part. The conductivity of the plate is very low (0.001).

This is causing me all sorts of headaches. Any chance of a fix?

 

 

Edited March 26, 2016 by allmhuran

[allmhuran]

In case anyone is thinking "meh, this is some weird custom scaled up part, so obviously this problem is never going to affect me"... I think you might care about this one:
 

 

[NathanKell]

@allmhuran no, it's not thermo. Engines heat parts by raycasting from their exhaust to find what they are hitting. Raycasts cast against colliders. PhysicsSignificance=1 parts don't have rigidbodies so don't have colliders to raycast against, IIRC, so the cast goes through them.

[allmhuran]

2 hours ago, NathanKell said:

@allmhuran no, it's not thermo. Engines heat parts by raycasting from their exhaust to find what they are hitting. Raycasts cast against colliders. PhysicsSignificance=1 parts don't have rigidbodies so don't have colliders to raycast against, IIRC, so the cast goes through them.

If that were true, then why does the behaviour of the girder change when the physics significance flag of the plate (and nothing else) is changed in the first gfy?

Here's another example:
 

 

And, just in case there's any suspicion that the engines are somehow heating the girder or the fuel tank directly despite not being directed at those parts, here's an image demonstrating that the fuel tank does not heat up at all if the decoupler is not there, with the craft otherwise identical.

The problem is absolutely something to do with physics significance and thermo.




 

Edited March 26, 2016 by allmhuran

[NathanKell]

Ok, I'll look into it when I have a sec. That's very weird, because AFAIK we don't check for physics sig anywhere in thermo!

[allmhuran]

@NathanKell I did some additional testing, Kasuha did a little too.

Our conclusion: It looks like there is no extra heat, rather the physicsless part is simply transferring the incoming heat directly to its parent instead of heating up itself, in the same way that it transfers its mass and its drag to its parent.

Then it is in turn heated by convection from the parent.

So, for exampe in the test with the fuel tank, the engines raise the temperature of the decoupler, but the decoupler then sends that temperature directly to the fuel tank, so the fuel tank gets hot while the decoupler does not. Then thermo runs and says "oh there's a fuel tank that's 1900 degrees next to a decoupler" and transfers some heat back via conduction, so the decoupler heats up to ~500 degrees.

Whether this then becomes circular (and potentially also unnecessarily taxing on the CPU), I do not know. But (without seeing any code) that's the best guess: The problem is not anything specifically coded into thermo about physicsless parts. Its just the more general behaviour of physicsless parts transferring their physical properties directly to their parent. It seems like this technique works quite well for mass and drag, but can't be used for temperature because of the fact that temperature can move between parts.

 

Edited March 27, 2016 by allmhuran

[Geschosskopf]

10 hours ago, allmhuran said:

@NathanKell I did some additional testing, Kasuha did a little too.

Thanks for doing this.  This is truly fascinating and scary, and I hope there's still time to fix this before 1.1 comes out.  Your testing explains some of the weird stuff I've seen.

[NathanKell]

@allmhuran one further question. Can you get that behavior under any other heating scenario, or is it only with engine exhaust heating?

[allmhuran]

@NathanKell I first discovered it when I was playing with BD Armory, which IIRC sets the temperature of a part directly in code. I'm at work right now but will check other methods tonight - I'll try engine heating via internal conduction, solar radiation, re-entry... hrm, is there anything I'm missing?

Edited March 29, 2016 by allmhuran

[NathanKell]

@allmhuran thanks! Nah, I'm mostly just wondering if for some reason the engine code in particular is doing something odd, or if it's something else. Like, do they not take reentry heating?

[allmhuran]

Roger that, it'll be about 8 hours before I get a chance to investigate and provide details.

[NathanKell]

@allmhuran as I suspected it's engine exhaust heating, nothing to do with the thermo system per se. However, the engine exhaust heating shouldn't be skipping the part.

Here's why this is happening. As it stands now, the engine exhaust damage, after it raycasts and detects a hit, finds the root transform of whatever transform it hits. And physicssig=1 parts are parented to the part that has full physics. So that 'root' check gives the parent part, not the hit part. If you watch closely in those gifs, you'll see that the convective flux of the decoupler is negative. That means it is being cooled by its environment, not heated. By contrast, the convective flux of the full-physics parent part is very high--that's where the exhaust heat is going.

[allmhuran]

Yep, I did some tests and the temperature values are only "backwards" with raycasted stuff - which I guess really just means engine exhaust as far as regular KSP is concerned.

This is probably why I found the issue via the BD Armory mod. It does a  Physics.Raycast, and then says the hit part is the raycast.rigidbody.gameObject.

It sounds like you're saying that, at the moment, KSP will return the parent of the physicsless object when this method is used. Is that correct? And if so, I guess that means it would be true for anything using raycasting, not just temperature related stuff - but I can't think of much else that would depend on it. Maybe collision detection in general?  So it's not possible to crash into physicsless parts? I dunno, I obviously can't see the code.

Actually, I could test that by throwing stuff at a large decoupler and checking to see whether it's actually the parent part that gets broken....


Edit: Waaaait a minute, BD armory lasers use the exact same code (albeit in a different file, but the method is identical), but those don't have this problem - the physicsless part temperature increases as expected. I will mention this to the author of the mod but it's very confusing! The only difference I can think of is that the "per update" increase in temperature of a BD armory bullet hit is much larger than the laser, which heats an object over a longer period. I realise I'm now talking about mod code but it all uses stock KSP thermal physics, all the mod does is set part.temperature.

Edited March 29, 2016 by allmhuran

[allmhuran]

Oooherr, interesting. This "backwards heat" thing isn't just for physicsless parts. In the image below, you can see from the sparks that the BD Armory bullets are hitting the small fuel tank, but the big fuel tank is much hotter. I wonder if this is somehow due to the fact that the temperature is being increased by larger quantized per-update amounts than would happen via the laser (or an exhaust).

Redacted.  Looked at the mod code, for this specific case this is a direct mod effect and not related to KSP thermal physics. The only core game issue is that of heat being applied to the parent of physicsless parts under certain circumstances, as already confirmed.

Edited March 29, 2016 by allmhuran

[NathanKell]

Let me clarify.

Prior to my change last night, KSP raycasted to get a hit transform. Then, KSP said use (thattransform).root and looked for a Part component on _that_ transform's gameobject. This is because the transform you hit might be a submodel (say, the nozzle of the engine), and the Part component is on the parent of the parent of that transform.

However, only full-physics parts are the roots of their own hierarchies; non-full-physics parts are themselves children of other parts. So that code is not safe to use. Now, KSP checks upwards and stops when it hits the first  Part component it finds.

[allmhuran]

Thanks Nathan.

Edited March 30, 2016 by allmhuran
misread

[NathanKell]

Thanks for the great reporting and followup! There's good reason why I thanked you and Kasuha in the dev note from me.

[allmhuran]

No, thank you for such a quick turnaround time. I'm amazed you got to look into this so quickly with all the 1.1 stuff happening.