[0.21+] Kosmos Spacecraft Design Bureau: Updated (9/27/13)

[NoMrBond]

I wonder if it's because of the way Unity handles the conversion of .TGA to DDS, and if .PNG has the same issue (beyond the .PNG slow loading glitch).

[Edit] Reading suggests .PNG's are the 'lesser of evils' for textures, and to use PNG's unless your textures have an alpha channel, in which case you want a .TGA, but it's all a bit vague and there's a of of dissent about it

Edited October 5, 2013 by NoMrBond

[NathanKell]

Is it true of uncompressed TGAs as well as compressed TGAs?

It might be that the memory page used to put the uncompressed version into is never freed.

(pipeline: read file into memory space A. If file is compressed, allocate space B and uncompress into space B. Then pass pointer to A (or pointer to B if step 2 was necessary) to DDS compressor.)

[CardBoardBoxProcessor]

Eh. it is a slight bit overly busy but it will do.

[MOARdV]

[Edit] Reading suggests .PNG's are the 'lesser of evils' for textures, and to use PNG's unless your textures have an alpha channel, in which case you want a .TGA, but it's all a bit vague and there's a of of dissent about it

Lots of people assume that file size is equivalent to the amount of memory a texture uses. It isn't. *ALL* textures with the same dimensions use the same amount of memory when loaded. A 1024x1024 RGB image will require 3 megabytes of RAM (and video memory), regardless of if it's a 3MB MBM or a smaller TGA or PNG image. If there's an alpha channel, 1024x1024 requires 4MB. If the image is converted to a DXT format, the image size is still directly proportional to the dimensions of the source image - file size has no bearing on this.

The problem with PNG is that KSP or Unity (don't know which) does not create a full mipmap chain for the texture, so you end up with sparklies and other artifacts, so the quality of the image suffers when you're not close to the texture. MBM and TGA both create mipmap chains. The only upside to PNG is that it uses a lossless compression algorithm that makes it smaller than MBM (which is a raw RGB or RGBA bitmap with a 20 byte header) or TGA (which is either a raw bitmap or a run-length encoded bitmap). However, from an image quality perspective, the lack of mipmaps is hard to miss if you are paying attention. TGA seems to be the best trade-off, since it allows reduced bandwidth via RLE, and it is an accessible format for most image editors, allowing the end-user to resize it smaller if they have significant memory pressure.

[Commander Gizmo]

Lots of people assume that file size is equivalent to the amount of memory a texture uses. It isn't. *ALL* textures with the same dimensions use the same amount of memory when loaded. A 1024x1024 RGB image will require 3 megabytes of RAM (and video memory), regardless of if it's a 3MB MBM or a smaller TGA or PNG image. If there's an alpha channel, 1024x1024 requires 4MB. If the image is converted to a DXT format, the image size is still directly proportional to the dimensions of the source image - file size has no bearing on this.

The problem with PNG is that KSP or Unity (don't know which) does not create a full mipmap chain for the texture, so you end up with sparklies and other artifacts, so the quality of the image suffers when you're not close to the texture. MBM and TGA both create mipmap chains. The only upside to PNG is that it uses a lossless compression algorithm that makes it smaller than MBM (which is a raw RGB or RGBA bitmap with a 20 byte header) or TGA (which is either a raw bitmap or a run-length encoded bitmap). However, from an image quality perspective, the lack of mipmaps is hard to miss if you are paying attention. TGA seems to be the best trade-off, since it allows reduced bandwidth via RLE, and it is an accessible format for most image editors, allowing the end-user to resize it smaller if they have significant memory pressure.

I think that pretty well sums it up. Couldn't have put it better myself! Thanks for adding some clarity.

[NathanKell]

MOARdV, that's spot on, with one little exception: given that a chunk of the memory usage spikes is from leaks, it's not clear that the original format will have _no_ bearing on the final memory usage; as I mention above, there's a chance that if their code leaks, having to uncompress an image before converting to DDS may (since that memory leaks) cause more usage.

It'll take some SCIENCE! to test this all out.

[NoMrBond]

It seems odd that since everything is converted to DDS internally for Unity (dxt1 by default or dxt5 for textures with alpha) that .PNG doesn't get mips, I wonder why

[CardBoardBoxProcessor]

It seems odd that since everything is converted to DDS internally for Unity (dxt1 by default or dxt5 for textures with alpha) that .PNG doesn't get mips, I wonder why

known unity 4 bug

[NoMrBond]

known unity 4 bug

I am sadness.

PNG's don't get mips, and the memory used to decompress .TGA's doesn't get released properly (in some cases), how... vexing.

Edited October 5, 2013 by NoMrBond

[wasmic]

known unity 4 bug

I heard that the png bug would be fixed in KSP version 0.22 when it updates the unity whateverthingy.

EDIT: Those engines on the previous page... they're awesome!

[MOARdV]

MOARdV, that's spot on, with one little exception: given that a chunk of the memory usage spikes is from leaks, it's not clear that the original format will have _no_ bearing on the final memory usage; as I mention above, there's a chance that if their code leaks, having to uncompress an image before converting to DDS may (since that memory leaks) cause more usage.

I'm a GPU guy by trade working in x64 exclusively, so I tend to think in terms of GPU address space first. You're right, of course, about CPU address space impacts. If there are memory leaks because interim memory's not being released during the transformation from file format to GPU format, there can be some drastic memory impacts. I think I'll go do some MBM / TGA experiments before lofting my Mun Space Station.

[blizzy78]

I have some problems with the RD-0146-N2. For testing, I've used a simple craft:

- RC-001S Remote Guidance Unit

- 2x FL-T800 Fuel Tank

- RD-0146-N2

On launch, I've activated SAS and launched straight up. No touching the controls. This is what happened:

- Liftoff as usual. Specfic impulse of the engine starts to rise.

- At 200 m, specific impulse starts to drop from about 190.

- Until 5400 m, specific impulse drops dramatically to about 56.

- Specific impulse starts to go up again.

- At about 8700 m, the engines goes out because the fuel tanks are empty.

The problem seems to be in the engine's atmosphere curve:

	atmosphereCurve
 	{
   	 key = 0 451
   	 key = 0.05 300
  	 key = 1 188
 	}

If I comment out the line with 0.05 atmospheric pressure, the craft performs MUCH better and continues to climb until flameout at 260 km.

Is the engine supposed to work that way? If so, it is not really suitable for ascent because of the sharp drop in the middle of the curve.

Also, the RD-0146 has a similar curve, but the increase at the end is not as steep, so the drop in the middle should not be as much.

[wasmic]

I have some problems with the RD-0146-N2. For testing, I've used a simple craft:

- RC-001S Remote Guidance Unit

- 2x FL-T800 Fuel Tank

- RD-0146-N2

On launch, I've activated SAS and launched straight up. No touching the controls. This is what happened:

- Liftoff as usual. Specfic impulse of the engine starts to rise.

- At 200 m, specific impulse starts to drop from about 190.

- Until 5400 m, specific impulse drops dramatically to about 56.

- Specific impulse starts to go up again.

- At about 8700 m, the engines goes out because the fuel tanks are empty.

The problem seems to be in the engine's atmosphere curve:

	atmosphereCurve
 	{
   	 key = 0 451
   	 key = 0.05 300
  	 key = 1 188
 	}

If I comment out the line with 0.05 atmospheric pressure, the craft performs MUCH better and continues to climb until flameout at 260 km.

Is the engine supposed to work that way? If so, it is not really suitable for ascent because of the sharp drop in the middle of the curve.

Also, the RD-0146 has a similar curve, but the increase at the end is not as steep, so the drop in the middle should not be as much.

I think it was supposed to be

key = 0.5 300

instead, that would make more sense.

[NoMrBond]

I think it was supposed to be

key = 0.5 300

instead, that would make more sense.

Hrm, no it's meant to be very bad in the atmosphere starting at 188 ISP at sl but increasing to 300 in the high atmosphere and then to 451 in pure vacuum, the 0.05 was meant to avoid the situation you have with the NV's where they have ~75% of their ISP (~600 or so) already by 3000m

It shouldn't be dropping below 188 (there should not be a drop in the ISP curve), maybe the rocket mode atmosphereCurve can't handle multiple points (or they're interacting in unexpected ways), sorry about that.

[Edit] I think I get what's happening now, the FloatCurve for the atmosphereCurve has the two upper points defined very close together (0.05 and 0) so it gives the part immediately below 0.05 a massive negative slope (Y is dropping from 451 to 300 within an X distance of 0.05) which troughs the curve. Very sorry about that one, I'll make a better curve.

Edited October 5, 2013 by NoMrBond

[wasmic]

Hrm, no it's meant to be very bad in the atmosphere starting at 188 ISP at sl but increasing to 300 in the high atmosphere and then to 451 in pure vacuum, the 0.05 was meant to avoid the situation you have with the NV's where they have ~75% of their ISP (~600 or so) already by 3000m

It shouldn't be dropping below 188 (there should not be a drop in the ISP curve), maybe the rocket mode atmosphereCurve can't handle multiple points, sorry about that.

Oh, is he talking about the vacuum engines? In that case it makes sense. I can never remember which of the engines is which, it's all just RD-AAA-BC

[NathanKell]

It can, but you might need to use tangents.

[CardBoardBoxProcessor]

It can, but you might need to use tangents.

they are not linear they are beizer curves. So you need a seocund point right next to that point graphically to balanc it out.

[NoMrBond]

It can, but you might need to use tangents.

Yes I was thinking the iTan and oTan variables should allow you to define the direction of the curve coming off the point, unfortunately the post defining the FloatCurves of the atmosphereCurve and its variables has vanished.

they are not linear they are beizer curves. So you need a seocund point right next to that point graphically to balanc it out.

Yep, I'll get onto that, I don't think having four points on the atmosphereCurve causes any issues I'll just pay attention to how the curve is exiting the points this time.

Edited October 5, 2013 by NoMrBond

[melvincat]

I am new to ksp, so this is probably a dumb question. When I go to the vehicle assembly building and start building, after 30 seconds the game crashes after I look at a new part. When I see the part in the menu it is clear, like the texture is supposed to be their. Is there anything I can do?

Log

http://pastebin.com/7YFV2Fgn

Persistent

http://pastebin.com/6p0AbLxy

[wasmic]

How did you install the pack? I've never seen behaviour like that before.

EDIT: The correct way to install the pack is to simply drag-and-drop the KOSMOS folder into the GameData folder.

[ashrutoraman]

zip archive is corrupt

[MDBenson]

zip archive is corrupt

It's not, you need to copy the URL into a download manager and download it that way. If your download takes longer than a certain time on the Spaceport and you are only using a browser to download it will stop before it's complete and corrupt your download.

[Jaybtlr]

Hey there, love the new URM parts, and id love them more, but there seems to be a pretty significant problem. Thankfully, it isnt a memory issue... it just seems that the URM parts lag my computer too much. In the VAB, i cant manipulate my rockets once even partially constructed as it causes the scene to drop frames horrendously.... the same goes whilst in flight... none of my creations nor those provided, provide lag-free launches.... that is, unless, i use <20 or so part rockets, which (being a 1.25 only pack for the time being) means i cant launch anything with any significant tonnage. I my build does allow me to launch creations in excess of 200 parts stock or otherwise without frame droppage being much cause for concern. Any tips?

[CardBoardBoxProcessor]

Hey there, love the new URM parts, and id love them more, but there seems to be a pretty significant problem. Thankfully, it isnt a memory issue... it just seems that the URM parts lag my computer too much. In the VAB, i cant manipulate my rockets once even partially constructed as it causes the scene to drop frames horrendously.... the same goes whilst in flight... none of my creations nor those provided, provide lag-free launches.... that is, unless, i use <20 or so part rockets, which (being a 1.25 only pack for the time being) means i cant launch anything with any significant tonnage. I my build does allow me to launch creations in excess of 200 parts stock or otherwise without frame droppage being much cause for concern. Any tips?

like all things KSP the devs probably made it and left it half finished. so it is probably not optimized at all... So I am sure it is something only they can fix.

look at plantary annilations. 1000s of units on screen and no FPS lag at all.

KSp. 10 URm 1 length tanks and lags like hell. It jsut needs to be optimized code wise i am sure.

[NoMrBond]

Thankfully a large part of 0.22 (beyond R&D and subassemblies) is optimizations.