Jump to content

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


Recommended Posts

  • 4 weeks later...

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

cKnKvOU.png

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

AYJBj9p.png

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.

Link to post
Share on other sites
  • 2 weeks later...
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 by Fwiffo
Clarification
Link to post
Share on other sites

First things first: I fixed it!

VgmlFMf.png

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 by jaredkzr
Link to post
Share on other sites
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...

bdBMM7e.png

 

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

Link to post
Share on other sites
  • 1 month later...
On 17/02/2016 at 9:53 PM, Ficko said:

bdBMM7e.png

 

Then I delete most of the MODs in Gamedata and problem solved.:D 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 by Bluebottle
Link to post
Share on other sites
  • 2 weeks later...

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

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Link to post
Share on other sites

YD5y6Da.png

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

BOXy4Pb.png

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

SCE0utF.png

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

zR1drrn.png

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

mo6V1Uo.png

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 by Gaiiden
Link to post
Share on other sites
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

mo6V1Uo.png

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.

EQvNItz.png

bUoYwqZ.png

 

 

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.  

Link to post
Share on other sites
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!

Link to post
Share on other sites

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

Link to post
Share on other sites

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 by wheels27
added more of the Python code for clarity
Link to post
Share on other sites
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?

Link to post
Share on other sites
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 by Bluebottle
Link to post
Share on other sites

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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...