KSPBlender - Blender Addon for importing .craft files (now with complete mod support!)

[Denko666]

Extrmely cool project;

Just have 1 question though: how long should it generally take to import a .craft file? (few seconds? one or two minutes? an hour?...)

[bananashavings]

Weird, textures not working correctly for me. I can import the file, and the model is correct, but none of the textures are in the correct position. http://imgur.com/BxFOg0I

Edited December 30, 2015 by bananashavings

[Ficko]

can import models in 1.02 and 1.04, with some problems in 1.05 like this 

and models' textures didn't fit well (in both 1.02 and 1.04)

I used the source code on the GitHub released on 5 Oct 2015. Blender's version is 2.73

 

==

At first I couldn't even use the code later than Mar 25, 2015,  because after that the author changed a method to list the 'part' (part_dir.py  --> part_dict.py). Finally I realized it was encoding error. I followed Cptman's instructions (in Page 13) and problem solved.

[Fwiffo]

On 1/27/2016 at 7:30 AM, Ficko said:

some problems in 1.05 like this 

I had similar UTF-8 decoding errors trying to open craft files generated by KSP 1.0.5.  Fixed it by editing import_craft.py and part_dict.py to use latin-1 rather than utf-8 encodings, and I can now import my craft into Blender!

Two lines changed in import_craft.py:

if platform.system() == 'Windows':
    kspdirfile = open(direc+'\\kspdir.txt','r',encoding='latin-1') # Changed from utf-8 to latin-1
else:
    kspdirfile = open(direc+'/kspdir.txt','r',encoding='latin-1') # Changed here too for good measure; untested
kspdir = kspdirfile.read()

One line changed in part_dict.py:

#rescale_fact = 1
f=open(os.path.join(path,cfg),'r',encoding='latin-1') # Changed from utf-8 to latin-1, and added "readonly" semantic
part_path = ""

Make your browser window nice and wide when viewing this; these silly new forums don't understand that code blocks shouldn't be line wrapped.

Edited February 11, 2016 by Fwiffo
Clarification

[jaredkzr]

First things first: I fixed it!

It turns out that the UV maps were being incorrectly flipped along the x-axis which caused the objects to receive the wrong parts of textures from the texture files. I dove into the python files and found the culprit: line 237 of the import_craft.py file. 

Originally the offending chunk of code looked like this:

                    if len(obj.data.uv_layers):
                        if "_fixed" not in obj.data.uv_layers[0].name:
                            obj.data.uv_layers.active.name+="_fixed"
                            for uvvertex in obj.data.uv_layers.active.data:
                                uvvertex.uv[1] = -uvvertex.uv[1] + 1		

Notice that negative sign in front of the uvvertex.uv in the last line? That's the problem. Just get rid of it and your UV maps will be correct! I'm guessing that it was originally a workaround for some weird KSP texture handling that got fixed in some update. 

So, to reiterate, remove the negative sign in front of uvvertext.uv[1] in line 237 of import_craft.py to fix the texture problem.  

 

Now that this is fixed, I'm going to play around with it some more and finally realize my dreams of creating a decent rocket launch in blender!

Edited February 14, 2016 by jaredkzr

[Ficko]

On 2016/2/11 at 1:58 PM, Fwiffo said:

I had similar UTF-8 decoding errors trying to open craft files generated by ...

 

On 2016/2/14 at 1:11 PM, jaredkzr said:

First things first: I fixed it!

...

Many thanks! My UVtexts now can working properly!

 

===

At first it can work well only in KSP1.0.2 in my computer. As I change kspdir.txt file into KSP 1.0.4 or 1.0.5, it just goes wrong again....confusingly...

 

Then I delete most of the MODs in Gamedata and problem solved. I don't know why but it is solved...

[Bluebottle]

On 17/02/2016 at 9:53 PM, Ficko said:

 

Then I delete most of the MODs in Gamedata and problem solved. I don't know why but it is solved...

This is because the relevant 'if' statement that tests for matches with "position=" also matches things like RealHeat's "...Decomposition=". I fixed it by adding a whitespace check to that match, which means that line 118 in part_dict.py simply needs a "\b" added:

if "\bposition =" in line and not(got_pos):

 

Edited March 18, 2016 by Bluebottle

[GalaxG64]

Hi I was wanting to print a few crafts from KSP, I saw a few pics from printed stuff. Im running this on a Linux machiene running specifically arch on 64 bit.

Where do I have to point the kspdir file to, Ive read through the post and there was a question like this but it was never answered because the author solved it by himselfe. so to which directory do I point this mod.

Thx for the help

Alexander

[Bluebottle]

9 hours ago, GalaxG64 said:

Hi I was wanting to print a few crafts from KSP, I saw a few pics from printed stuff. Im running this on a Linux machiene running specifically arch on 64 bit.

Where do I have to point the kspdir file to, Ive read through the post and there was a question like this but it was never answered because the author solved it by himselfe. so to which directory do I point this mod.

Thx for the help

Alexander

As it says right in the readme.txt, the kspdir.txt contains the full directory path where your KSP.exe lives.

[GalaxG64]

Well I dont have an KSP.exe, Im running linux, so the Syntax of the directory path changes, Im sure that I set it correctly so to the /path/to/Kerbal\ Space \Program directory, but im still getting the problem described.

Thx Alexander

[Csongor Kerman]

To me the texture is messed up.

EDIT: It's working now!

Edited April 3, 2016 by Csongor Kerman

[Vulkaistos]

Hi 

Thanls for making kspblender.

But could you please at the parts of USI Survivability to the compatible ones, because they always give out an error?

 

http://imgur.com/glATd6K

Thanks

Edited April 5, 2016 by Vulkaistos
added Picture

[Drew Kerman]

Here's a render from 1.0.5, however the craft file was supposed to contain the rocket nose cone as well and while no errors were produced and the nose cone part is listed in the object tree it's not visible for some reason. I know there are issues with USI parts (Sketchfab exporter hates them too). Any suggestions?

ok it's something with parachutes, I can't see the stock or realchute nosecone chutes either (still no errors)

most of USI's stuff looks good (I removed some of the engine fairings) but again the issue with the invisible part - at the bottom is supposed to be the small aerospike engine

perhaps @RoverDude can provide some insight...

continued messing around and found that I can get the aerospike to show up only if I have a nosecone attached, even though the nose cone itself still doesn't show

however if I import the nosecone on its own as an .mu model it doesn't show textured in the 3D view like the craft import does but it does have a texture when you render it

however then after I import the craft into the same scene this is what I get

You don't see the aerospike in this last render because I took the nosecone off the craft thinking maybe it was because there was already a nosecone model loaded. I think I'm done fiddling around for now...

Edited April 8, 2016 by Gaiiden

[esinohio]

On 4/8/2016 at 7:16 AM, Gaiiden said:

/snip

however then after I import the craft into the same scene this is what I get

You don't see the aerospike in this last render because I took the nosecone off the craft thinking maybe it was because there was already a nosecone model loaded. I think I'm done fiddling around for now...

/snip

I can try and help with the last problem at least.  When you import a .mu the texture comes in all weird.  The information is there but the texture itself is in some odd state.  Easy way to fix this is simply to delete the texture on the nose cone and then make a new one.  Set it to an image texture and use the small dropdown to choose the dds file for the cone.  All fixed!  Fixed in that it will at least show the texture.  From there you can add in some glossy, bump, etc.

 

 

As for missing parts I think sometimes the last part gets orphaned somehow?  Really not sure on that one.  I just manually import the .mu and go from there.  Thankfully there are just a few rogue parts that don't like the script importer.  

[Drew Kerman]

appreciate the guidance. Will play around with what you've shown me and report back

[esinohio]

5 hours ago, Gaiiden said:

appreciate the guidance. Will play around with what you've shown me and report back

Feel free to message me anytime!  Can't wait to see your renders.

[Drew Kerman]

On 4/13/2016 at 9:55 PM, esinohio said:

As for missing parts I think sometimes the last part gets orphaned somehow?  Really not sure on that one.  I just manually import the .mu and go from there.  Thankfully there are just a few rogue parts that don't like the script importer.  

Finally got to try this out and you are correct - somewhat. So, when I said adding the nosecone made the engine appear, I took this advice and added a science instrument after adding the nose cone, and now the nose cone appears fine but so does the science instrument! So I guess it only partially applies to certain parts. But still, got all the parts I wanted imported properly with the craft model. thanks!

[Drew Kerman]

additional note for anyone importing a craft that has animations, you need to go into the User Preferences->Editing tab and enable the "Allow Negative Frames" option, that way when you scroll the timeline cursor backwards the animations play properly to unfold parts you want extended and such

[wheels27]

I started using this Blender add-on to convert my .craft files into .stl files for 3d printing.  Therefore, the colliders are not necessary and just clutter up the Blender file.  I was looking through the import_craft.py file and noticed some commented out lines (256 and 257) that seem to delete the colliders. 

if "coll" in obj.name or "COL" in obj.name or "Col" in obj.name or "fair" in obj.name and 'KSP' not in obj.name:                       		   # if it is named anything to do with collider, I'll have none of it
	obj.hide = True                 	# gtfo
	obj.hide_render = True          	# really gtfo (don't even render)
	#object.select = True           	# and if I'm really mad
	#bpy.ops.object.delete()        	# I could just delete it
	if obj.type != 'EMPTY':         	# and if it is a mesh (the empties have already been hidden, so this is a double-tap on them)...
		print(obj.name + " Hidden\n")   # ...let me know

I un-commented them and crafts failed to import properly and the result is different each time I try. 

Thoughts anyone?

 

Edited April 22, 2016 by wheels27
added more of the Python code for clarity

[jaredkzr]

On 4/22/2016 at 9:24 PM, wheels27 said:

I started using this Blender add-on to convert my .craft files into .stl files for 3d printing.  Therefore, the colliders are not necessary and just clutter up the Blender file.  I was looking through the import_craft.py file and noticed some commented out lines (256 and 257) that seem to delete the colliders. 

if "coll" in obj.name or "COL" in obj.name or "Col" in obj.name or "fair" in obj.name and 'KSP' not in obj.name:                       		   # if it is named anything to do with collider, I'll have none of it
	obj.hide = True                 	# gtfo
	obj.hide_render = True          	# really gtfo (don't even render)
	#object.select = True           	# and if I'm really mad
	#bpy.ops.object.delete()        	# I could just delete it
	if obj.type != 'EMPTY':         	# and if it is a mesh (the empties have already been hidden, so this is a double-tap on them)...
		print(obj.name + " Hidden\n")   # ...let me know

I un-commented them and crafts failed to import properly and the result is different each time I try. 

Thoughts anyone?

 

 

What error message do you get in Blender's log?

[KazeNinja]

So I just got the add ons today and I wanted to prep my model for school next week, however I keep getting a MK1 Cockpit error where it cannot seem to find it. Any solutions?

[skyress3000]

Science Jr.s won't import for me... anybody know what's going on? The console says "science.module_4294088456 not imported for some reason... let me know which part!"

[Bluebottle]

On 14/02/2016 at 0:11 PM, jaredkzr said:

It turns out that the UV maps were being incorrectly flipped along the x-axis which caused the objects to receive the wrong parts of textures from the texture files. I dove into the python files and found the culprit: line 237 of the import_craft.py file. 

Originally the offending chunk of code looked like this:

                    if len(obj.data.uv_layers):
                        if "_fixed" not in obj.data.uv_layers[0].name:
                            obj.data.uv_layers.active.name+="_fixed"
                            for uvvertex in obj.data.uv_layers.active.data:
                                uvvertex.uv[1] = -uvvertex.uv[1] + 1		

Notice that negative sign in front of the uvvertex.uv in the last line? That's the problem. Just get rid of it and your UV maps will be correct! I'm guessing that it was originally a workaround for some weird KSP texture handling that got fixed in some update. 

So, to reiterate, remove the negative sign in front of uvvertext.uv[1] in line 237 of import_craft.py to fix the texture problem.  

 

Now that this is fixed, I'm going to play around with it some more and finally realize my dreams of creating a decent rocket launch in blender!

I've found that this fix is actually incorrect. It's a band-aid over the real problem: somewhere along the line, the textures are being vertically flipped during the import. I've yet to find out whether it's happening in the .mu importer or KSPBlender, or maybe in Blender itself. The biggest issue is that exporting back to Unity requires either all the textures to be vertically-flipped, or you have to manually flip the UVs and offset them back down onto the UV square, to emulate the effect of a flipped texture.

edit: it's actually just DDS handling. All DDS textures have to be flipped, for 'reasons'. What's annoying is that the Unity editor doesn't demand this and displays DDSs "properly", while the game needs them to be flipped.

Edited May 2, 2016 by Bluebottle

[Bluebottle]

Two bugs found.

Bug 1: The .cfg parser chokes on commented "mesh" statements. These are present in some of the Near Future Construction parts. For example:

Spoiler

// Near Future Construction 0.5.0
// NOTE: not part of [trusslrg-1] because of collider finneckiness
// 2.5m Truss - Hollow
PART
{
	name = trusslrg-hollow-1
	module = Part
	author = Chris Adderley

	//mesh = trusslrg-hollow.mu
	rescaleFactor = 1
...

 

Removing the "//mesh" line made the KSPBlender parser work again. With that line in the file, no "trusslrg-hollow-1" parts could be imported by the script.

Bug 2: The part database builder will count backup .cfg files from some text editors as valid .cfg files and load a part twice, which means that none of those parts will be imported into Blender. I had several .cfg~ files (note the tilde character) lying around in my GameData, which normally cause no problems whatsoever, but KSPBlender considers them valid and loads them. You need to delete such files, at least on Linux.

[ckirky]

err.. it calls up when i import a save ship that i dont have the part (missing part)

this also happens fors stock

help?