Some definitive answers. If you can.

[Guest]

Export .dae from sketchup. Import the .dae into blender. Switch to edit mode in blender. This is important! Press "a" to select entire model. Press "f" to make solid faces and remove triangulation. Now you can remove double vertices which are probably what is causing problems with your sketchup models. While the entire model is still selected, look through the menus on the left and click "remove doubles". Now you can do the uv map and make your textures. Finally, make sure you are in object mode(important!), and save as a .blend. Unity will the import the .blend which contains the uv map and all you have to do is import you texture and bingo! Now as far as collision meshes are concerned, I'm not very knowledgeable, but I think unity will create those for you with just the check of a little box, and as long as the model is clean, with no doubles, you might see better results. Here is a video I made to help visualize what I just said : http://forum.kerbalspaceprogram.com/entries/1386-Sketchup-to-Blender-to-Unity-to-KSP

Good luck!

[AlphaAsh]

Some interesting tips there, thanks Otis. I definitely want to be using Blender more as a post-process for Sketchup models and have no intention of switching to Blender. Like you say in your video, it's waaaay too overly complicated. I was a professional game developer many years ago and whilst I can appreciate that the technology has moved on, my oh my is this a pain compared to what I used to use. Most unintuitive software ever.

I'm not seeing a benefit to UV mapping over single texture per material for the stuff I'm currently making, especially since I re-use the same batch of textures and keep all my models in one folder. The memory foot-print for KerbinSide is pretty small and since I have models with hundreds of edges, I'm in no hurry to start unwrapping such monsters.

One question, if I may. How the kerbal hades do you remove doubles on everything in one go? Doesn't matter if I select everything in Object Mode. As soon as I switch to Edit Mode, Remove Doubles only works on a single mesh at a time. My current model has 300. I'm not going to be doing them one at a time

[nli2work]

I don't know about blender... maybe try select all while you are in edit mode. Command-A or Ctrl-A, almost universal shortcut for that. There should be some kind of combine operation in Blender that lets you combine multiple mesh objects in to one. This is available in every 3d app I've ever used in passing, but a lot of times they call it different things.

as far as general 3d practices go, 300 mesh objects is bad. you want to combine them into one continuous mesh for best efficiency. basically, for every mesh object, the game engine has to make a request " hey computer render this!"... same goes for material and texture. You can see how for 300 mesh objects with 300 materials this spirals into enormous amount of draw calls. Now imagine doing this for a dozen; few dozen; a few hundred objects in the scene. This is why frame rate drops with large ships; why KSP unloads objects further than 2.5km from you; etc.

Do you have to do your best to make your designs as efficient as possible? no. but you should.

What kind of game dev did you do if you don't mind me asking?

Edited July 2, 2014 by nli2work

[AlphaAsh]

I exaggerated. The model only has nine materials but even with proper intersection, Sketchup likes to break complex models down rather too much. And yes I am a lazy modeller.

Game development wise, I did some work for the ye olde MechWarrior arcade pods. Some stuff with BioWare and Microsoft Studios. Mostly donkey work. EDIT - Some environment modelling (aka mapping), concept art and 3D prototyping for environmental and architectural assets (trees, buildings etc.) and some concept art and 3D prototyping for characters. It was not glamorous and it was not fun

Edited July 2, 2014 by AlphaAsh

[AlphaAsh]

Do you have to do your best to make your designs as efficient as possible? no. but you should.

That's actually something I'm having to work on more than I am used to. With concept and prototyping work, it wasn't such an issue because someone else would worry about that. Which explains a little why I like SketchUp and why I'm a lazy modeller.

Removing doubles in Blender doesn't seem to be making any noticeable difference to a model in Unity and KSP. I have finally confirmed that there's no need for reverse/interior materials in a model and that it was a major cause of more than one material appearing on a (sub)mesh. Big "well duh" moment obviously. Combined with not exporting two-sided faces, I'm getting some really good stuff out of SketchUp, through Blender to sort out the hierarchy, into Unity. Colliders are 99% fine now just by avoiding any open geometry colliders.

[AlphaAsh]

A few things learnt over the last few weeks posted here for reference for myself and newbies:

- You can have more than one material on a mesh. However, KSP will get confused as to which to render and seems to always render material 0. Might as well get rid of second materials on a mesh in Unity.

- You can attach any number of colliders to a mesh object in Unity. They don't have to be separate objects themselves.

- Colliders generally don't have to overlap. They're fine in contact with each other. With longer edges, KSP's physics may sometimes still see gaps between colliders. Then a little overlap is worth considering, although this may lead to bumps instead of gaps. Use overlapping colliders sparingly. Consider 'cutting up' a model to shorten edges.

- Hatches are an utter nightmare. When making pods, plan waaaay ahead if you intend to have a working hatch. Consideration for hatches will heavily compromise any model design.

- SketchUp's DAE exporter will screw up model hierarchy that doesn't work correctly in Unity. Filter a SketchUp DAE through another model program to another Unity compatible format. Blender does a good job of fixing the hierarchy of a SketchUp DAE exporting to FBX.

- Don't export double faces or edges from SketchUp in a DAE. Do export hidden edges.

- Import textures into Unity as jpg. Unity seems to munch up TGAs sometimes. KSP's part tools can convert your jpg to TGA for you when you output your part.

- Use the correct version of Unity and the correct version of KSP's part tools. There's a lot of contradiction over what's the correct versions. This is a pain everyone seems to have to go through apparently.

Edited July 17, 2014 by AlphaAsh

[nli2work]

A few things learnt over the last few weeks posted here for reference for myself and newbies:

- You can attach any number of colliders to a mesh object in Unity. They don't have to be separate objects themselves.

- Hatches are an utter nightmare. When making pods, plan waaaay ahead if you intend to have a working hatch. Consideration for hatches will heavily compromise any model design.

- Import textures into Unity as jpg. Unity seems to munch up TGAs sometimes. KSP's part tools can convert your jpg to TGA for you when you output your part.

- Use the correct version of Unity and the correct version of KSP's part tools. There's a lot of contradiction over what's the correct versions. This is a pain everyone seems to have to go through apparently.

I'm pretty sure KSP will only read the 1st collider component on a mesh object. The rest are discarded, either in game or by part tools. Multiple colliders require multiple game objects child to the parent object with Part Tools component. Will have to test it some more

Hatches are a pain, make sure the Hatch trigger only intersect 1 collider on the model. Capsule collider might work better than box collider in some instances.

There was some discussion as far as best texture format for KSP. But going into Unity I suggest a non-compressed format like TGA or BMP. JPG is a compressed format and going back to TGA from JPG won't improve the texture quality. From Unity to KSP I settled on TGA Compressed for easy of editing later, load-time, 32bit RGBA, and final size.

For KSP, best version of Unity seems to be 4.2.2; if you already have a large project in a newer version, there are some fixes to allow more complete legacy animation functionality.

[DMagic]

I always use PNGs for Unity. You might want a better PNG plugin if you're using Photoshop, but I think it's better than JPGs either way.

[nli2work]

I switched to TGA Compressed after reading a thread on PNG loading time issues due to a bug with Unity, PNGs resulted in dramatically longer loading time compared to TGA or MBM formats. It may or may not be applicable now.

here's the thread by Novasilisko

http://forum.kerbalspaceprogram.com/threads/35225-Some-lesser-known-bits-of-info-for-addon-developers

[DMagic]

I use TGAs for KSP too, I just meant that for importing textures into Unity I use PNGs. The file format is more universally recognized and I never have problems opening or editing PNGs in any kind of software, so they seem to be the simplest format to use while creating textures.

[nli2work]

Oh I gotcha. Yeah PNGs are good as well. Anything lossless is preferable going into Unity.

[AlphaAsh]

I'm pretty sure KSP will only read the 1st collider component on a mesh object. The rest are discarded, either in game or by part tools. Multiple colliders require multiple game objects child to the parent object with Part Tools component. Will have to test it some more

Very good point. I'll look at this again. It may explain some odd behaviour I'm getting from one part's colliders.

"Hatches are a pain, make sure the Hatch trigger only intersect 1 collider on the model. Capsule collider might work better than box collider in some instances."

There's definitely some magic combination needed to get hatches working. That's one ingredient of the spell, yep. Still experimenting to confirm others. Still only got one working hatch on one of five pods.

"There was some discussion as far as best texture format for KSP. But going into Unity I suggest a non-compressed format like TGA or BMP. JPG is a compressed format and going back to TGA from JPG won't improve the texture quality. From Unity to KSP I settled on TGA Compressed for easy of editing later, load-time, 32bit RGBA, and final size."

I went with jpg because of the reliability of the import. Will certainly try something else if it retains quality better.