Somewhere to put any knowledge learned about using the .mu plugin.

[ColdJ]

1 hour ago, Watermel00n said:

When I try to export as .mu, this happens.

Going to need a lot more information. Version of program, version of plugin, specific problem etc.

I usually use the export function up on the top right with blue box.

Most obvious thing I can see in your pic is that you haven't got "FuelCell1" highlighted in the right side heirachy and if it is not highlighted then there is nothing to export. Though having said that I opened up mine and the export option is still available even without highlighting.

So yeah, assuming you have read all the way through the thread for answers and followed how to install correctly, that you are using the correct version of the plugin with correct version of the program and like, then going to need to know what led up to this pic, was all working before?, is this the first time you have tried etc.

(is also best practice to have your mesh inside an empty axis in the heirachy, I can see there you just have the mesh on it's own.)

Could you show if you have added a material to your model please.

Edited May 16, 2022 by ColdJ

[Watermel00n]

What is a material? I have a UV texture, is that it?

 

Edited May 16, 2022 by Watermel00n

[ColdJ]

As seen in this pic on the right hand side, a material is what contains the shader information and the name or names, (depending on the shader) of the texture pics used by your mesh, this info is stored in your .mu when you export along with the UV map data, which is why all your vertices get multiplied around 5 times when you export. So if in your meshes heirachy you don't see that brown, yellow and white pie chart then it doesn't have a material set up and when you import it back in after export there will be no mesh saved, just nothing there. There is info in the thread in various posts that are helpful.

@Watermel00n

[Stone Blue]

What ColdJ said above, *except* for the "import it back in after export", part.... you shouldnt be re-importing the mu

Edited May 16, 2022 by Stone Blue

[Rodger]

Just in case you haven't seen it, I put some random tips in the wiki section of the github page for the plugin: https://github.com/taniwha/io_object_mu/wiki/Rodger's-mostly-unedited-tips-for-making-new-KSP-parts-in-Blender,-without-Unity and https://github.com/taniwha/io_object_mu/wiki/Animating-for-KSP

May be somewhat out of date (from 9/2020), but should be mostly good still.

[Stone Blue]

Yeah.. the wiki is really good reference...... I have a few more, detailed things I promised Taniwha I would add... I *really* need to do that Soon(TM)

[ColdJ]

21 minutes ago, Stone Blue said:

What ColdJ said above, *except* for the "import it back in after export", part.... you shouldnt be re-importing the mu

Except for the problem that a .blend file will remember everything and load it up fine each time you work on it, but once you export as a .mu and you load it into your game to test, only to find nothing there, you will then try loading it back in BForArtists to see what is wrong. Unfortunately it is not a perfect world and there is a learning curve and other things go wrong.

I know that idealy it is recommended that you only export once but when you are constantly testing and refining you often end up doing it more than once. As long as you remember to "Merge by Distance" all the meshes as soon as you import in to remove the excess vertices then you are fine. Also sometimes you are modifying someone else's .mu and so you have to do this anyway to clear the excess vertices on the original.

I have literally had to reimport things I am working on, hundreds of times and as long as I follow the routine I am fine.

So lets make it that you save as blend and work from blend till you finish as much as possible but if it is needed you can reimport and follow the routine and be ok.

Thanks @Rodger I will copy your tips into here so that people on the forum can view them here as well. The first tips I read are also in a you tube video I posted a link to, further back in the thread.

The following is information provided by Rodger on the Github page.

In the same directory as your .blend, create a new .cfg file for your part, and add .in to the end of the file name (partname.cfg.in). There is a template included in the addon which includes calculations for volume/mass based on the mesh, but you can also just copy a stock cfg to start with.

Once the cfg.in file is in the directory, when you export the part, the exporter will add certain things to a new cfg file it'll create based on the cfg.in: Empty objects called node_XXX will be turned into NODE{} definitions (single arrow helps see their rotation, but empty type doesnt matter). For surface attachment nodes, call the empty node_attach, and the exporter will add a "regular" node definition with the location data in it, as NODE{} doesn't work for srf attachment. The location of empty objects called CoMOffset, CoPOffset, or CoLOffset will be used to set CoM/CoP/CoL.

Make sure your cfg.in has rescaleFactor = 1.0 and scale = 1.0. Otherwise KSP defaults to a 1.25 scale, so a 1m part in blender will come out as a 1.25m part in KSP.

Create an empty as the "root" part for your part, and name it the same as your part.cfg.in file (without the .cfg.in extensions). Child your meshes, colliders, and other transforms(empties) to this (shift drag the objects on top of the root empty is one way to do this). Make sure your meshes have their transforms applied (crtl A), so the transform panel reads 0° for the rotations, and 1.0 for the scale. Then select the root object, press clearInverse, double check nothing's out of place (colliders will move if you moved them originally via transform panel), then press the export mu model button. It will create a .mu file with the name of the root part, and a .cfg file too.

If something's out of place in-game, selecting the root object, and pressing the clearInverse button and then re-exporting will most likely fix it.

The exporter will strip all ".xxx" suffixes, so you can have multiple instances of the same name in KSP, even when blender adds the numbered suffix to differentiate different instances with the same name.

Add colliders via add mu collider tab inside the tool menu, or button at top. adjust size on creation, or in Mu Collider panel to adjust colliders size/location, inside the object properties panel of the properties editor, not the blender transform location/scale. Rotation needs to be done with blender's transform panel, but doesn't seem to cause any issues (and you seem to be able to get away with translations too). The isTrigger option makes a non-solid collider, for ladders/hatches etc. (you can use Sarbian's DebugStuff to view colliders in-game - https://forum.kerbalspaceprogram.com/index.php?/topic/135726-18-debugstuff-2019-10-22-see-the-hidden-secrets-of-the-game-objects/)

In the Mu Shader panel of the material properties tab, select the KSP shader you want to use for the part (the dropdown menu should have entries like "KSP Diffuse", "KSP Bumped Specular" etc). If you don't have the list of shaders, you just need to press the 'install KSP shader presets' button in the preferences of the .mu addon. Then in the textures tab, Name: _MainTex, under that change 'grey' to your diffuse texture name. same for different maps eg _BumpMap (from bump to your normal map) or _Emissive (from white).

For flag objects, go to the Mu Properties panel, (object properties panel of the properties editor), in "Tag:" type in and add Icon_Hidden, which will hide the flag mesh from the part tray. The flag mesh's UV map should be square to show the flag correctly, even when the mesh is the right aspect ratio (W = 1.6*H). Set the mu shader of the flag mesh to alpha translucent

For parachutes, the model needs to be made with Y+ being "up", then "adopted" (set child) to an empty object, which is then rotated X+90° so the chute appears correct with Z+up in blender. The semi-deploy and fully deploy animations both need to start at frame 0, with the fully deploy starting position being the same as the end of the semi-deploy anim.

 

Firstly for animation with key frames, rotation needs to be in quarternions, not eluer. You can still use eluer to edit, just change to quarternions before applying keyframes and blender will convert for you:

"taniwha: if doing continuous rotations, because unity's curves are quaternion-only, you need to animate two full revolutions (in steps < 1 revolution) to avoid weird things happening at each revolution"

Next ether change the timeline editor to the nonlinear animation editor, or make a new space to have both:

Then you'll see "actions" with the keyframe data in them:

Then you need to push down the keyframe data into an NLA track, by pressing the button Push Down Action:

All tracks need to start at frame 0, for example semi and fully deploy parachute animations, both need to start at 0 even if you make them one after another.

Then double click the NLA track's name and rename to what you want the unity animation clip to be called:

You can name multiple NlaTracks the same name, and they will all be grouped together by the exporter, and played as one animation when activated by a KSP module. You don't need to merge them in blender (you can't anyway)

You can still edit the keyframes of an NLA track by selecting the track so it's yellow, and pressing tab or right click it - start tweaking strip actions (it should turn green). Then you can just edit or add keyframes as normal:

You can convert an animation to quarts by using a dummy object with constraints and animation baking:

0. animate the thing you want
1. make a new object/mesh/whatever
2. add a constraint to the new object, copy rotation, and set the animated object as the source
3. bake that constraint animation, so it doesn't have a constraint anymore, just its own keyframes (keys every frame)
4. then, set the original thing to use quart rotations in the transform panel, and then repeat the last 2 steps, this time constraining the original object's rotation to the dummy objects. then bake the animation again, but this time since it's set to quarts, it'll key in quarts!

[Rodger]

Reimporting will cut the mesh up into uv islands iirc. So that can make working on stuff a pain, compared to having access to the original. Reimporting can be a decent check to see if everything exported correctly. If you want to clear your blend file of old stuff, there’s ways to do that in the object browser, or in drastic cases copy the original meshes into a fresh blend, would be better than a reimport.

[ColdJ]

2 minutes ago, Rodger said:

Reimporting will cut the mesh up into uv islands

Could I get a bit more info on this please?

When I reimport my UV maps are exactly as I made them with no obvious change, so what are you saying is happening?

[Rodger]

The mesh itself will be split into sections corresponding to the uv islands, which is why you’ll get the duplicated verts

[taniwha]

12 minutes ago, ColdJ said:

Except for the problem that a .blend file will remember everything and load it up fine each time you work on it, but once you export as a .mu and you load it into your game to test, only to find nothing there, you will then try loading it back in BForArtists to see what is wrong. Unfortunately it is not a perfect world and there is a learning curve and other things go wrong.

Import is not meant to be part of a workflow other than an initial import of a model for which the "source" (blender/maya/whatever file) has been "lost". I gave up on full round-trip support for import/export years ago. In fact, due to triangle vertex order issues, 100% round-trip support never existed.

The intended workflow is to use the blend file as the model's source file, and export as needed. There's even script (mass-export.py) provided to facilitate doing whole scenes of models (makes it much easier to ensure model sets fit together and can even share sub-models).

There are scripts in the addon directory for debugging exports. animprop.py, bones.py, cump.py, hierarchy.py, and the nuclear powered big stick: mucfg.py.

[ColdJ]

@taniwha

Hi. I am constantly learning and it is great to get more information. I am not someone who understands coding though. So while you are here.

What is the definitive reason that the vertices get multiplied?

 

[taniwha]

3 minutes ago, ColdJ said:

What is the definitive reason that the vertices get multiplied?

Because .mu files are just dumps of Unity mesh objects, and mesh objects are optimized for the gpu, so each vertex is identified not only by its position, but also UV coordiinats, normal vector, tangent vector, and vertex colors. Thus as soon as you add a UV seam, or split normals (eg, flat shading), vertices must be duplicated in order to have the different properties at the same point in space. Short story, a vertex can have only one UV point, only one normal, etc etc

Blender's edit-mesh format is optimized for editing: the one vertex can have multiple sets of attributes (multiple UVs, normals, etc). I won't go into details on how blender does it (for one, it uses more than one internal representation, for another, my head is full of Quake BSP stuff right now)

Mesh editing and mesh rendering are two very different worlds.

[ColdJ]

2 minutes ago, taniwha said:

Mesh editing and mesh rendering are two very different worlds.

Thank you. I think I understand in a general kind of way.

Hopefully this info will help others.

[Stone Blue]

@ColdJ when you say: "Except for the problem that a .blend file will remember everything and load it up fine each time you work on it, but once you export as a .mu and you load it into your game to test, only to find nothing there, you will then try loading it back in BForArtists to see what is wrong. "

You are NOT re-importing the mu into your *working* blend, are you? .... you should open a seperate *blank* file/blend, and re-import into *that*, to see whats wrong... and do *no* edits in that file... that blend should just be for *looking*.... if you want to make edits, then you do those in your *working* blend, export the changes from *there*...

The blank blend you imported to, as I said, is just to see how it re-imports... it's *disposable*...once you are done looking... close it *without* saving it

There are times where I need to make *major* changes to my working blend, and if I think there may be a chance new changes may destructively set me bac, I save my working blend *before* maing the changes, and usually append a number suffix, or shorthand description of that last major change i made....

AFTER saving it, i immediatly save again, but rename it with a higher number suffix, or shorthand description of the major chnge(s) I am *about* to make...
Basically, i am making a seperate backup .blend, i can go bac to, without having to start all over. I know Blender/BFA can be set for periodic, *automatic* backups... (which i also have set), but these end up not usually being very useful, except in the case of a Blender/BFA crash, or my actual blend gets corrupted.

i also make *extensive* use of the History buttons, as I am working, to step bacwards when immediate edits need to be reset. i also have the "steps to remember" number in the History setting, set to maximum... (256, IIRC)

Edited May 16, 2022 by Stone Blue

[ColdJ]

2 minutes ago, Stone Blue said:

i also make *extensive* use of the History buttons, as I am working, to step bacwards when immediate edits need to be reset.

Due to the way I learnt and a lack of detailed information, my process ended up being different from what you are used to. I understand what you and taniwha and rodger have said, and I will try to get in to the habit of working with blend files to create and only export what I hope is finished. But due to the issues I had when I lost hours of work due to a blend file refusing to export as a .mu, I am still a bit gun shy to using that method. The way I do it has worked well for me, especially once I understood to clean up imported models with merge by distance. Hopefully I have understood it right that blender can work with multiple aspects at a vertice, but that extra vertices need to added at each of those points in virtual space on export so that Unity can access all the various extra data for each point.

I do make extensive use of the undo and undo history menu items if that is what you are referring to. If something hasn't worked or if I see I made a serious mistake that I had missed.

I do also consecutively number each time I save so that if something goes seriously wrong or I really don't like a change I have made, I can go back to a previous iteration. I also save very regularly, as many times I have been well into crafting, only to have the blender program suddenly shut down without warning, forcing me to have to do all that work again.

So mostly yes, I do it in a similar fashion to you.

[ColdJ]

Been adding some updated info and clarification to the second post in.

[taniwha]

On 2/25/2022 at 1:15 AM, Stone Blue said:

3rd pic showing what "Single Arrow" does. (I do not recall, how this one gets determined, which axis it does, but IIRC, generally, it automatically points to Z.) i find this one *most* useful, when doing those tricky orientations, where you NEED to have that certain axis, pointing correctly, or cant figure out *where* exactly, your thrust/gimbal/dockingnode, etc axis is currently pointing

I just want to make something clear here: while the single arrow does indeed point along the local Z axis in blender, the exporter knows how to translate the orientation of certain objects between blender and KSP.

• empties: this is based on name. If the name starts with "node_", or is "thrustTransform" (full match). This is where the single-arrow empties shine.
• camera: unconditional
• light: unconditional

This means you can place special objects intuitively in blender and they'll work in KSP.

 

On 2/27/2022 at 10:04 PM, Stone Blue said:

I'm not positive, but it might be, that when you export the .mu, the plugin "translates" Blender left-hand orientation, to Unity right-hand. (The X-axis being to left, vs right)
It *might* do this same translation, upon *import*, changing Unity rotation back to Blender rotation... ??
Which might mean its cumulatively doing it every time you export/re-import the .mu... ?? I dont know.

This is part of the "round trips not supported" bit of the addon. Yes, special objects are rotated on export, but only lights and cameras are on import.

Edited May 22, 2022 by taniwha

[ColdJ]

UV mapping.

This will attempt to give a straightforward example of how to UV map a model.

Here I created a simple cylinder and linked it to a Material set up from another model so that it can use a texture pic I had already created. The simplest way to paint a model is to assign different parts of the model to a colour panel in a simple texture pic.

The KSP shader used in that setup is the sort that you need to detatch the Vertex colour in Shading or it will look pitch black.

Now that we can see the texture on the cylinder, we can see it is using it's default created UV map, that covers the whole pic.

I want it to have yellow on the ends and red around the outside, so I go in and select the vertices on the end of the cylinder and then use the navigation keys to give it the orientation I want to look at. I then click on the UV drop down and select "Project from view" This then projects that view on the overlay panel seen on the right. As it is bigger than the colour panel I resize it in the overlay panel and drag it over the right section.

I then click on the "Viewport Shading ball up on the top right to see what it looks like.

Now to do the sides. I choose only half the side at a time, otherwise the end disc would get highlighted again. And repeat the process but put the result over the red panel. Once done you can see the 4 sections overlayed on the right.

So here is the finished product, on the right you can see if you scroll down in the materials section where the KSP shaders are and where you can edit to determine what texture pic your material set up looks for. It should always be kept in the same folder as the model.

@An Amongus Sussy Player

 

Edited May 25, 2022 by ColdJ

[ColdJ]

@Stone Blue.

It happened again. Blender happily saved something that the .mu plugin couldn't reconcile. Didn't find out till I tried to export as an .mu  . I had to go back through 6 hours of blend saves till I found one that would export. So that's 6  hours of work I had to redo from scratch. That is why I prefer my method. It means remembering an extra step but you find out quickly if something is wrong.

[Rodger]

You can keep exporting .mu files to check them as you go, but just avoid re-importing them after you check them?

[ColdJ]

59 minutes ago, Rodger said:

You can keep exporting .mu files to check them as you go, but just avoid re-importing them after you check them?

I had been doing that before, just tried to do it blend as I kept being told I should. I am going back to the way I was doing it before. I quite often need to test things in game and so have to go out and then come back and change things. I have had no problem as long as I remember to merge by distance when I import. I have had no real world proof to show me anything wrong with doing it my way. Doing it the other way means having to double up on all saves and I would still have to import a previous .mu if I get a problem as saving as a blend file does not show the problem.

As you and @Stone Blue have been at this longer than me, have you any other info you could add to this thread from your experiences? I do my best to pass stuff on for new people starting out to try, but surely I can't have covered everything.

[ColdJ]

@Geonovast

You have opened my eyes to a few things today. I hadn't looked at the Wheesley in 3d modeling before. I see that it actually has 2 thrust transforms and that they don't actually turn a full 180, possibly because they have heat exhaust turned on.

I also hadn't realised that you can animate empty axis to change position without being linked to a mesh.

More things learned today.

 

[taniwha]

On 5/29/2022 at 1:20 AM, ColdJ said:

t happened again. Blender happily saved something that the .mu plugin couldn't reconcile.

I'm sorry, but this is not at all helpful. What went wrong? Exception? Incorrect model?

As a potential bit of help: I recently "fixed" an exception that would occur when attempting to export a model that has a mesh with 0 vertices. Of course, this is not a valid thing to do, but the exception was rather unhelpful to anyone who couldn't parse it. It now skips the offending mesh and provides a helpful message (including the name of the object), thus the quotes around "fixed".

Anyway, just like KSP mods: logs or it didn't happen. (ie, I need you to help me help you).

[ColdJ]

9 hours ago, taniwha said:

Anyway, just like KSP mods: logs or it didn't happen. (ie, I need you to help me help you).

Sorry, I didn't realise that I could ask for help resolving the issue, I had just been mentioning it to @Stone Blue as it had happened again and that is why I am reluctant to save everything to a .blend file until I am finished, rather than export as an .mu, because if I export then I find out much more quickly if something has gone wrong.

I will look to see if I still have a blend save that will cause the issue. I think it had something to do with how I had cut a model into parts that would be separate parts in the game and then patched the cut ends that would show. I ended up patching them a different way and that worked once I had redone everything.

Anyhow I will go have a look and if I have the file to replicate and get the error log I will post and tag you.