Discussion in 'Modding Guides and Tools' started by Harag, Feb 6, 2015.
I don't know. Probably, considering skeletal animation normally only rotates the bones. Just try
I put a preliminary new version of the addon on GitHub. This version significantly changes how the node-tree that drives the export to SE provides settings to Blender's FBX exporter. Each MwmBuilder node in the tree now has most of the FBX exporter settings on its extended properties panel.
By default these settings are supposed to be the same as before this change, meaning existing .blend files should export the same as before. But... just to be sure, save your .blends to a new name before trying this version of the addon with the copy.
Now that these settings can be tweaked a MwmBuilder node can be used for other things than block models. For instance now you can import SE_astronaut.fbx to model your own character. The screenshot above shows which settings need to be changed to export a character to SE. The link on GitHub has a .blend where the astronaut is already imported and the exporter node-tree is already customized.
I'd appreciate feedback to squash any bugs that might have crept in.
Omg! Harag, you are awesome!!! I will test it out as soon as I get a chance, and I'll let you know if I get any bugs.
I made a small addition to remove some of the guesswork about which settings are the right ones: Presets
The settings for characters and animated poses work with the TheAstronaut.blend I attached to version 0.7.0-alpha.1.
Nobody reported any problems so here is release 0.7.0.
great work on the blender tools Harag.
i was able to finally get my model ingame but no matter what i try the textures are not showing up. just stays black.
i'm getting the "Could not find Materials library folder." error on the .mwm.log.
The warning message is normal. What does VRageRender-DirectX11.log have to say? Does it report any problems with textures or materials?
nothing, but this:
2016-04-17 10:41:04.750 - Thread: 7 -> Mesh asset Models/Debug/Cone.mwm has inconsistent vertex streams
2016-04-17 10:41:04.750 - Thread: 7 -> Mesh asset Models/Debug/Cone.mwm has no material in part 0
2016-04-17 10:41:19.169 - Thread: 7 -> Unloading session data
im not making a cone, i think this is keen.
Hm, these are all the reasons a texture can be black I can think of right now:
No normal map (you can use fake_ng.dds as a placeholder)
A black AO channel (set the red channel of your _add.dds to full intensity to have no AO)
The texture paths are not relative to the base of your modfolder / .blend file.
This odd problem.
im using stock SE textures just renamed. so the textures shouldn't be the problem.
all textures and .blendfile are in the same mod folder. I've tried everything, I'm using blender 2.76?
is there a simple blender test file zip that you can send me as a working example? or can i send you my stuff so you can check it out? thanks for the help.
Usually...when I have had black object issues it has been down to a mis-typed path in the SBC or XML files.
The textures need to be in the MOD folder in a Textures sub directory....so make sure you have that structure in the Appdata/Roaming/SpaceEngineers/Mods with your mod folder having a copy of the texture files in. Then your pathing should just be Texture/texture name.dds. If you are referencing the textures in their original location...that might not work.
Then check carefully for typos in the text files.
I know when I was getting my head around modding, the textures and materials part was the most awkward. Everything else was easy by comparison.
I am in the process of picking it back up again to make myself some new thrusters, as I am bored with the stock and don't like the assumption that large ion thrusters should be 5 times longer than the diameter....so I am making myself a set that better suit my personal taste. I also want H2 thrusters that look like rocket engines
Heads up guys. I was banging my head for a couple nights trying to figure out why my exported FBX and the subsequent MWM models didn't have any material properties with them (verified this using VRageTools) and why I was getting a warning in the export log about not being able to find a materials library.
Turns out that you need to have at least one texture assigned to a texture slot for each material in the Blender Renderer. It doesn't have to be a real texture but having materials setup for Cycles alone will not suffice.
Yes, that is a problem. Here is a more detailed set of instructions to get rid of it.
I get the error that mwmbuilder failed without an appropriate exit code. This occured after getting an error that mwmbuilder could not be found and I changed the location in finding it to the new location within the games VrageEditor folder.
Take a look into one of the .mwm.log files in your export folder then. Those should contain more detailed error messages.
I am getting the same error. Nothing in the log I can see. The mwmbuilder I WAS using has gone, and it's now in the same place as Zanzikahn had to go to get it. The model I was trying to convert worked fine before the update last week...and now fails
Running from: C:\Users\John\AppData\Local\Temp\tmpuc4nje49
Command: H:\STEAM\SteamApps\common\SpaceEngineersModSDK\Tools\VRageEditor\Plugins\ModelBuilder\MwmBuilder.exe /s:Content /m:FM_Thruster3_Large.fbx /o:.\
Could not find Materials library folder.
System.BadImageFormatException: Could not load file or assembly 'AssimpNet, Version=18.104.22.168, Culture=neutral, PublicKeyToken=0d51b391f59f42a6' or one of its dependencies. An attempt was made to load a program with an incorrect format.
File name: 'AssimpNet, Version=22.214.171.124, Culture=neutral, PublicKeyToken=0d51b391f59f42a6'
at MwmBuilder.MyModelBuilder.Build(String filename, String intermediateDir, String outputDir, MyModelConfiguration configuration, Byte havokCollisionShapes, Boolean checkOpenBoundaries, IMyBuildLogger logger)
at MwmBuilder.ProgramContext.ProcessItem(ItemInfo item, String outputDir, Byte havokCollisionShapes, Boolean checkOpenBoundaries)
at MwmBuilder.ProgramContext.ProcessFile(String file, String outputDir, Dictionary`2 defaultVars, Boolean exportXml, Boolean forceBuild, Boolean checkOpenBoundaries)
at MwmBuilder.ProgramContext.ProcessFileSafe(String file)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
--- Automerge ---
Tried it with and without a collision mesh in layer 2. Made no difference.
A model file IS created ...but it does not display in game and just appears as a black box that murderd framerates.
I will refrain from posting my log file as it is exactly the same as FlakMagnet's log. The only difference is the location being exported to and I only get a collision model and LOD1 but only as .FBX files. Also want to note that the model being exported has already been exported to the workshop. I am only revisiting the model to reduce the amount of triangles. I have also attempted re-exporting a previous model that has not changed and get the exact same error. I do feel changes in the SE update is the cause. The fact that the location of the MwmBuilder.exe file moved to another directory furthers my assumption. I don't see how a changed location can adversely affect the add-on even though I corrected the location the add-on is to look in. The new location is "Steam\steamapps\common\SpaceEngineers\Tools\VRageEditor\Plugins\ModelBuilder\MwmBuilder.exe"
If this helps in any way.
Hm, MwmBuilder fails to load one of its own code libraries. I'll need to investigate why.
Oh that is not good, lol. I suppose this means that Keen themselves have failed to update a library reference. Thank you for looking into this.
i get the same here too; I'm not able to export. thanks again.
Same here. I notice though I can run MwmBuilder independently of the plugin and it works but I only get the exception when running it from the plugin.
I'm tempted to try and hook Visual Studio up to it and see what is going on under the hood because apparently it's, somehow, managing to load a malformed DLL or something given the System.BadImageFormatException being thrown.
UPDATE: I did some digging and debugging to discovered the BadImageFormatException is coming from whenever the XML serialization generator kicks in on the Assimp assembly.
That BadImageFormatException error seems to be the CLR puking at something it doesn't like about Assimp; I'm thinking it might be a 32-bit/64-bit incompatibility thing.
I did notice some silent exceptions in the background when debugging that Mwmbuilder.XmlSerializers.dll failed to load with a file not found exception so I tried getting the SGen tool to run manually but it refuses to generate Mwmbuilder.XmlSerializers.dll so either I'm doing something wrong or I am clueless (latter is more likely) but I'm thinking this Assimp assembly is probably at fault ultimately.
Oops forgot to post here: MwmBuilder is simply broken. It also fails when it is run manually on the console. Older versions of MwmBuilder still work.
That's not good. I have posted a bug report.....but it's dropped off page with no indication that anyone has noticed it. Will have to try and raise it on a stream or similar.....
Thank you Harag for this blender plugin!
It works really well for me. It's way more convenient than my previous modding setup, especially since it doesn't crash for no reason (or at all)
I have a few minor problems though,
1) using the Cycles Render, textures don't show. Maybe I missed something in the manual about it? This is really minor as I don't need pretty renderings, I only need a basic textured rendering for UV-editing and the Blender Render still works.
2) mount points planes are sensitive to face normals orientation. If not oriented "outside", SEBT will produce garbage mount points data. Not a big problem now but it was quite head-scratching at first
3) can't have collision cylinders on any axis other than Z (in blender) or use rotated collision boxes, which forces the use of expensive convex hulls. I guess I could mess with Front and Up axis in the export to use cylinders on any axis, but it'd be quite a pain and simply applying rotations on rigid bodies would solve both at once. I know it's doable, I could do it manually (and painfully) in Softimage Mod Tools back when it didn't crash upon model selection. IIRC you have been working on an experimental Apply Transforms On Export option; I wouldn't need it at all if not for primitive rigid bodies.
Look at that, they all find the way back here
Have you set your Viewport Shading to Material? If you are trying to view the games Dx11 textures you are out of luck. They are BC7-compressed .dds files which Blender is not able to load. You'll have to convert them first (to .png or whatever).
Hm, the mount points should not produce garbage. They are projected onto the side they most closely align with rotation-wise. So if they are aligned with the left side they will produce definitions for that side even if you visually place them on the right side. I usually have Shading > Backface Culling turned on so that this doesn't happen to me. The "Mount-Points" button creates six planes for you that are already rotated correctly. If you have symmetrical sides you could also define one side and produce the other with the mirror modifier. Anyway, mount point calculation is the oldest piece of code in the addon. If you can spot an error, be my guest: mount_points.py.
As long as you apply transformations (Ctrl+A in Blender) rotated cylinders should work because for whatever reason Havok ignores object-transforms when deriving physics shapes from the mesh input it gets. Sadly, even if you apply transforms Havok always fails to determine the orientation of a box that is not axis-aligned. I haven't found a way to make this work (it could be that's an optimization trade-off in Havok). Be warned that Bullet, Blender's physics engine, will draw its physics shapes (green outlines) out of place if you apply transforms. Just ignore that.
Thanks for the reply. So,
1) using the Cycles Render, Viewport Shading to Textured or Material gives white and grey, respectively. But I'm using the original SE textures, thus BC7-compressed. I'd avoid bothering with a conversion, also cause I'm worried it would fuck things up on export if the material points to .png instead of .dds and it's a very minor thing anyway. Just knowing why it's grey and that it's "normal" behavior is good enough for me as long as I can UV-edit using the DX9 texture and things export right
2) when I read "aligned with the side" in the the manual, I understand "the mount point is centered somewhere on the side and coplanar with it", not "the mesh can be placed anywhere as long as the normal is oriented towards this side". That was the confusion I guess.
3) yes, un-applied transformations are completely ignored; it behaved the same in Softimage Mod Tools. However, the big difference between Blender and SMT is: SMT first creates a primitive that you can apply transforms to, then build a rigid body that matches the primitive perfectly, preserving rotations; whereas with Blender there is no primitive, only meshes, the rigid body thing can't optimize the mesh covering since it doesn't "know" the mesh is actually a rotated cylinder for example. If you apply rotations, the mesh gets rotated but the rigid's cylinder loses it's rotation and go back to Z (and gets resized in order to cover the thing). So, since un-applied rotations don't matter anyway, in Blender a cylinder's main axis is always Z. But I know it's doable, I could and did with SMT. Or, maybe this Bullet outline position bug also applies to cylinder's orientation? I thought it merely visually centered the rigid on the object's Center point by applying the object's transforms on it, nothing more. If I'm not wrong about it, I guess the only way to do it is to first get the rigid's primitive and then apply transforms on it, instead of applying transforms on the mesh and then getting a rigid primitive cover around it.
It's not exactly a bug that Blender draws the physics shapes out place when you apply rotations. One is not supposed to do that with Bullet. Maybe it wasn't the wisest decision to re-use Blender's physics data for Havok but now I have to stick with it. I also have a GitHub issue about the applied transformations. I haven't addressed it yet because it's just so much work to create a temporary scene, copy all the meshes with physical properties to it and then apply transformations by code - compared to a simple Ctrl + A from the UI, that is.
And sadly there is no easy way to transfer primitives from Blender to Havok. Under the hood the meshes are exported to .fbx which in turn is run through Havok's fbx importer to convert it to .hkt. As far as I know .fbx doesn't have primitive shapes, only meshes and I'm pretty sure the importer wouldn't be prepared to handle primitives, anyway.
Yes, this Bullet problem is not really a Blender bug. If anything, it's an issue in SEBT.
Hmmm, if the primitive handling was some magic specific to the Havok addons for SMT/XSI, then there not much we can do about it :/
Except write a custom, direct, .hkt exporter, of course. Which would be quite a big task though a useful one now that Havok is no longer distributed
I'm having problem with making window/glass option. it just shows up as glowing white/pinkish. is that option broken? thanks.
Separate names with a comma.