https://i.imgur.com/qCsCJg5.jpeg
MK1 command module upscaled causes blur

MK2 command module upscaled causes camera disproportion, rendering the black pilot window in the camera view
https://i.imgur.com/JL4nTzC.jpeg

Those are the only two ive encountered so far.

ive enlarged mk3 as well, and MK3 looks to be alright and well

Yep, I confirm the problem.

This is the Mk1 and MK2 scaled up to 1.875:

And this is them scaled up to 2.5M

On the Mk1 case, the image is not exactly blurred - the camera was moved to behind the console, and we are seeing a very close close-up of the backside of the panel.

Interesting. Apparently something on scaling up the IVA.

I will check it - but it's improbable I can fix this, because it's probably related on how the camera view is set up on the mesh.

For the sake of curiosity, I redid the test on KSP 1.4.3:

1.875:

2.5:

And, indeed, it's directly related to the mesh - note how MK1 doesn't have the problem now.

I think I can code something do adjust the camera, a offset or something to be applied after scaling. This is something to think about.

However, since scaling up crewed parts are arbitrarily hindered by KSP's engine on launch, I don't think this issue is necessarily a priority at this moment. I will postpone it to a milestone where minor, cosmetic issues will be (or not) tackled down.

Thanks for the heads up, @Alexsys !

Better. I'm making this a co-issue to be handled together #44.

Interesting how older version tackle this specific code differently

Interesting how older version tackle this specific code differently

It's all about data structures. Meshes are merely data structures, no less, no more. You need code to transform the data into another kind of data that can be used to display something on the Monitor.

Any changes on the code may change the end result of that transformation, but changing the source data too - in fact, the code that renders ("transform from numbers into image") the MK1 are the same code that renders the MK2, and also the MK3.

On this specific case, the data used for the MK1 on KSP 1.12 is not the same data used on 1.4.3, the MK1 command pod was revamped recently - and on the revamp, they placed the camera marker on a position that, once scaled, moved the camera to a unhappy position. The same is happening on MK2 since ever.

Why this happens? Well, I will have to dig out the reason - but on a educated guess, I think we are seeing the misbehaviour of using floats when doubles are needed. If I'm right, the cameras are being slightly misplaced due roundings from double to float (and vice versa). What I will do, as soon as the time for it comes, is to revise the TweakScale code and minimise all conversions from double to float (and vice versa) in an attempt o reduce to the minimum the roundings (so the losses don't pile up).

With a bit of luck, the legacy TweakScale code is the culprit for the roundings and so I can rework it and "fix" the issue - but, frankly, historically KSP is the one using floats everywhere, so I will probably have to code something to counteract the mishap. Since KSP is screwing me up anyway on crewed modules, the place where this fix will be implement it's already planned (see #44) - so, again, thanks for the heads up. I had missed this use case completely.

In time: at the time KSP was born, CPUs were still 32 bits, and so using doubles would tax the processing - the supreme irony is that nowadays, using doubles are 30% faster than floats as everything is 64 bits and doing processing in 32 bits demands conversions - essentially, we would have a huge improvement on performance by changing everything to doubles and staying there.

Interesting how older version tackle this specific code differently

It's all about data structures. Meshes are merely data structures, no less, no more. You need code to transform the data into another kind of data that can be used to display something on the Monitor.

Any changes on the code may change the end result of that transformation, but changing the source data too - in fact, the code that renders ("transform from numbers into image") the MK1 are the same code that renders the MK2, and also the MK3.

On this specific case, the data used for the MK1 on KSP 1.12 is not the same data used on 1.4.3, the MK1 command pod was revamped recently - and on the revamp, they placed the camera marker on a position that, once scaled, moved the camera to a unhappy position. The same is happening on MK2 since ever.

Why this happens? Well, I will have to dig out the reason - but on a educated guess, I think we are seeing the misbehaviour of using floats when doubles are needed. If I'm right, the cameras are being slightly misplaced due roundings from double to float (and vice versa). What I will do, as soon as the time for it comes, is to revise the TweakScale code and minimise all conversions from double to float (and vice versa) in an attempt o reduce to the minimum the roundings (so the losses don't pile up).

With a bit of luck, the legacy TweakScale code is the culprit for the roundings and so I can rework it and "fix" the issue - but, frankly, historically KSP is the one using floats everywhere, so I will probably have to code something to counteract the mishap. Since KSP is screwing me up anyway on crewed modules, the place where this fix will be implement it's already planned (see #44) - so, again, thanks for the heads up. I had missed this use case completely.

In time: at the time KSP was born, CPUs were still 32 bits, and so using doubles would tax the processing - the supreme irony is that nowadays, using doubles are 30% faster than floats as everything is 64 bits and doing processing in 32 bits demands conversions - essentially, we would have a huge improvement on performance by changing everything to doubles and staying there.

Man, I read your wording on this and I see pure skill and knowledge in the stuff.

KSP 2 devs better employ this new business model of sponsering pro developers like yourself man, you keep their work in the skies and improve it even more.
They'd be wise to actually get a man like you on their board of KSP 2 maintenance, or mod developing, or whatever.
For a man of skill knowledge and will, any task in regards to that one passion is sufficient and good!
Cant imagine what skill and creation man like yourself will be capable if taken into such business model and actually funded to do this,
KSP 2 would turn into an eternal lifelong living BEAST