[0.22.X] BobCat ind. Historical spacecraft thread

[BobCat]

In game video settings have texture quality tab. Use them.

[KhaosCorp]

In game video settings have texture quality tab. Use them.

Setting texture quality to 'HalfRes' and rendering speed to 'fast' or 'fastest' will almost double the amount of mods you can have installed (give or take ya know).

Also there are texture reduction packs for Squad parts and a few popular mods floating around...fin them..use them.

[wasmic]

Setting texture quality to 'HalfRes' and rendering speed to 'fast' or 'fastest' will almost double the amount of mods you can have installed (give or take ya know).

Also there are texture reduction packs for Squad parts and a few popular mods floating around...fin them..use them.

Sadly, there is no texture reduction pack for this mod, which is pretty unoptimized - there is even a few 2048*2048 textures in this mod, which is a horrible waste of RAM. It'd be great with a texture optimization pack for this mod. Hmmm, I might actually make one myself. Does anybody know a good .mbm to .png or .tga converter?

[Guest]

Render speed to "fastest", texture quality to "Half-res". Little loss in quality (though it's noticeable) and great memory usage improvement.

[Virtualgenius]

if squad would optimise the stock parts we could run more mods, better still go to a 64 bit windows client

[KhaosCorp]

if squad would optimise the stock parts we could run more mods, better still go to a 64 bit windows client

Wouldnt hold your breath for that lol since there is a mod that does a very good job at it they will figure thats good enough...wouldnt be the first time =P

[Guest]

if squad would optimise the stock parts we could run more mods, better still go to a 64 bit windows client

I'm sure Squad will move toward releasing a 64-bit version of KSP when Unity finally get around to releasing a working 64-bit version of their engine for Windows and Mac. Until then, 32-bits is where we're at.

[wasmic]

I just did a bit of science. The result:

The stock parts use 426 mb and contains 168 parts - an average of 2.535 megabytes per part.

The Soviet Pack uses 516 mb and contain 103 parts - an average of 5.009 megabytes per part.

This is just a rough figure, though. I'll have to make some more thorough research later. However, you shouldn't say "Squad should optimize their parts" when someone says that Bobcats parts take up a lot of space.

[Herbert McCheese-Wang]

Sorry to be a pain but...

I'm having the Buran Manipulator Arm problem:

I have KAS, Robotic Parts and Lazor Systems installed

However when in the VAB I can't see the Lazor parts, so how are they installed? The KAS parts and robotic parts are in the VAB.

Many thanks

[BobCat]

wasmic

Your calculation wrong.

Example, Soyuz U + Soyuz TMA its 26 parts rocket and now look how much texture used this Rocket. Only 4.

Like Assembled MIR station used only 5 texture.

You dont know how working this mod , and make wrong calculation.

[Guest]

Actually, he's right. You've got a lot of shared textures, but because you're not using MODEL calls, KSP thinks they're all different. You could shave off a ton of memory usage with just a few config and file structure edits. I'll write you an e-mail explaining this further, I can even do this modification myself if you send me the list of parts that share textures.

Sorry to be a pain but...

I'm having the Buran Manipulator Arm problem:

I have KAS, Robotic Parts and Lazor Systems installed

However when in the VAB I can't see the Lazor parts, so how are they installed? The KAS parts and robotic parts are in the VAB.

Many thanks

There are no "lazor parts". Robotic arms are the only thing that Soviet Pack uses (there's also the docking cam, but that's automatically added to each dock).

Edited November 3, 2013 by Guest

[Herbert McCheese-Wang]

There are no "lazor parts". Robotic arms are the only thing that Soviet Pack uses (there's also the docking cam, but that's automatically added to each dock).

I used the docking cam in 0.21, and have got the BuranRoboticArm files in my GameData but it won't load!

I have no idea what I'm doing wrong.

[wasmic]

wasmic

Your calculation wrong.

Example, Soyuz U + Soyuz TMA its 26 parts rocket and now look how much texture used this Rocket. Only 4.

Like Assembled MIR station used only 5 texture.

You dont know how working this mod , and make wrong calculation.

The thing is, I measured the size of your parts folder, then I divided it by number of parts. All of the textures in your parts folder get loaded, even if some of them are identical. As dragon01 said, you could fix that by using model calls. You could get the memory usage down way below squads parts by doing that.

[Jaybtlr]

The KOSMOS pack does the same thing with the shared model calls, however what you save in memory and ram, you make up for with a lot of lag, both in the editor and flight scene. Its my understanding that KSP doesn't handle multiple model calls very effectively at the moment.

[Guest]

Note, that's only if you use multiple MODEL calls. If you've only got one (as with BobCat's Soviet pack), you'll have no problems. Since each module is modeled separately, just using a shared texture, there's no need for multiple calls.

[shaw]

@wasmic:

Measuring folder size to determine RAM usage is very misleading. First, both textures and geometry data is uploaded to GPU, so only a fraction of .mu file (node hierarchy, material data, node-based animations etc.) has to be kept in RAM. Unless you want to perform some shape deformation, animations on textures etc. Or the engine is poorly written. Second, texture is usually converted to a different format when uploaded to GPU. GPU doesn't understand PNG, JPG, TGA etc. Either raw uncompressed data or S3 texture compression (DXTn formats: DXT1 has compression ratio 6:1, DXT5 which is used for textures with transparecy has 4:1). Plus mipmaps have to be generated which increase texture size by ~1/3 (= 1/4 + 1/16 + 1/64 + ...). This step (mipmap generation + compression of each mipmap level) is usually far the most expensive part of loading a model and hence loading of KSP.

[BobCat]

Im still dont understand how use model call and how this help ?

[Guest]

I sent you another mail, hopefully it'll clear this up. This helps reduce the size of a big part pack by sharing textures and/or models between parts. This can be really awesome if you get used to it.

[Prowler_x1]

I sent you another mail, hopefully it'll clear this up. This helps reduce the size of a big part pack by sharing textures and/or models between parts. This can be really awesome if you get used to it.

Hi, could you share that info with me too?

[mahboi818]

Historical space craft has to be one of my favorite mods of all time

How did you get those stars? That looks a lot better than the default stars in the background.

[MDBenson]

How did you get those stars? That looks a lot better than the default stars in the background.

Probably Universe Replacer.

Keep up the good work Bobcat, can't wait to see what you come up with next

[wasmic]

@wasmic:

Measuring folder size to determine RAM usage is very misleading. First, both textures and geometry data is uploaded to GPU, so only a fraction of .mu file (node hierarchy, material data, node-based animations etc.) has to be kept in RAM. Unless you want to perform some shape deformation, animations on textures etc. Or the engine is poorly written. Second, texture is usually converted to a different format when uploaded to GPU. GPU doesn't understand PNG, JPG, TGA etc. Either raw uncompressed data or S3 texture compression (DXTn formats: DXT1 has compression ratio 6:1, DXT5 which is used for textures with transparecy has 4:1). Plus mipmaps have to be generated which increase texture size by ~1/3 (= 1/4 + 1/16 + 1/64 + ...). This step (mipmap generation + compression of each mipmap level) is usually far the most expensive part of loading a model and hence loading of KSP.

As far as I understand, the .mbm files that both Bobcat and Squad use take up just as much space after conversion as before. That is, a 1024*1024 .mbm will always be very close to 4mb, and they will also take up 4mb of space when converted to .dds format. To make it more correct, I even did some rough guesstimates about the .tga file in squads folder. Some of them take up 150 kb in the folder, but take up 4096 b when converted to .dds. Also, both bobcats and squads parts need to go through the mipmap generation

[NathanKell]

wasmic, shaw is right here. mbm is uncompressed bitmap, and the DXT1 version will indeed take up 1/6th the size (512kb for a 1024x1024, not 3mb). If the mbm has an alpha channel, it'll take up double that (only 1/4 the uncompressed size, which itself is 4/3 as big as the alpha-less mbm) (1mb for a 1024x1024, not 4mb).

[wasmic]

wasmic, shaw is right here. mbm is uncompressed bitmap, and the DXT1 version will indeed take up 1/6th the size (512kb for a 1024x1024, not 3mb). If the mbm has an alpha channel, it'll take up double that (only 1/4 the uncompressed size, which itself is 4/3 as big as the alpha-less mbm) (1mb for a 1024x1024, not 4mb).

Alright, thanks for clearing that up for me. Anyway, that doesn't change the fact that the soviet pack is a memory hog. A memory hog with really great parts, but a memory hog nonetheless.

[BobCat]

Im have old PC (4gb RAM and 512 Video memory) and allways use Sovietpack + American pack + KAS + Khetane and no any problem here, but im try solve this problem.