Bolt

Post the wall fbx file using Y-up option and I'll take a look at it.

There should be no axis conversion if you set your FBX exporter options to Y-up. FBX Export Options: Advanced Options -> Axis Conversion -> Up-Axis: Y-up Other than that, there is always the possibility that one of your parts is using negative scaling (-100) along one of their axes in 3dsmax. Some users do that when mirroring parts, but it may not export well outside of 3dsmax.

kuznec.fbx Your FBX file has no vertex normals. For a quick fix, make sure vertex normals are being exported with your FBX file. I have already made the necessary changes to fix this issue, so Josh may want to contact me. Send email to my hotmail address, because my hosting provider is currently experiencing a service interruption.

These files are required for the FBX converter: MSVC++ 2012 runtime redistributables: https://www.microsoft.com/en-us/download/details.aspx?id=30679 MSVC++ 2008 SP1 runtime redistributables: https://www.microsoft.com/en-us/download/details.aspx?id=11895 Select and download vcredist_x86.exe in both cases.

I don't know if this solves your problem, but the latest FBX converter requires the MSVC++ 2012 runtime redistributables: https://www.microsoft.com/en-us/download/details.aspx?id=30679 The converter is a 32-bit program, so you must select and download vcredist_x86.exe, whether you have a 32-bit or 64-bit operating system. I don't know if the Leadwerks installer comes with this file, but it's kinda important, especially for those who install Leadwerks on fresh install of Windows. And the older FBX converter required the MSVC++ 2008 SP1 runtime redistributables: https://www.microsoft.com/en-us/download/details.aspx?id=11895 So, I suggest installing both.

Just a guess, your model from Blender hasn't been triangulated. A model with concave N-gons could cause something like that, or if you're exporting a model with holes, make sure your model is triangulated.

I'll leave it to that.

Yeah, it went a bit off topic. I just wanted to add my input on the static mesh hierarchy issue, and not get dragged into a discussion about glTF.

Yes, it "can" be done, but that doesn't mean it should be done. Optimized runtime formats are not for editing. It's the job of your 3D modelling application to save your assets in a preserving, non-destructive way. When data is exported to an optimized format like glTF, precision is lost. Floating point values are truncated when exported to ASCII format, precision for vertex weights is lost when they get compressed to bytes, etc... And end users have no idea their data is being truncated because someone told them to export it between tools. File formats like FBX don't optimize your model data, because it's a true exchange format. And glTF will never replace it, because they're not competitors playing on the same level.

No, they used the word "interoperable" because they're describing an asset delivery system across different platforms. There's no need to convert/exchange a glTF file into another format when it's already been optimized to load into your game engine. I wouldn't use a runtime format like glTF or DirectX for editing purposes either. And whether glTF lives up to the hype remains to be seen. A lot people are pushing it, but I would rather hear who's using it.

Unwrap3D also has an importer for glTF files, but that doesn't change the fact that glTF is an end-of-the pipeline format. Importers are only there for convenience, for people who want to "decompile" runtime assets. And you won't find the word "exchange" anywhere on the Khronos glTF website, either.

Nothing has changed, it has always worked like that. The reason why a single root always gets exported is mainly due to animation reasons, a skeleton should only have one root. It's probably not required for static meshes, but no one has ever mentioned it until now. glTF is not an exchange format. It's a runtime format for game engines. The model data is written so game engines can load it directly into their buffers without modification. FBX, on other hand, is an exchange format, which is why glTF won't replace it. It'll just complement it.

I downloaded Akeytsu just to try it out. Their FBX import looks ok. I get the same smoothing results as them now. And I looked at the dwarf beard again, and it's actually the vertex normals that are reversed. The face geometry is ok. Akeytsu shows the same reversed normals too. As for Unity, it might have double-sided lighting enabled by default, so it doesn't show up as black. btw, I added a Split vertices per normal option to all the U3D FBX plugins if anybody wants to test it out.

Ok, I think I got it working. Vertices must be split by their normal when loading data into per vertex buffers. There are some artwork issues with your Dwarf model, btw, but the smoothing should now be correct. The two beard strands are black because the faces are reversed (you probably scaled them by -1 or they were procedurally created), and the left foot has one polygon assigned to the wrong smoothing group (user error).

The dwarf model has no smoothing groups, so everything gets smoothed as if it belongs to one smoothing group. To get this working with Leadwerks, the "armour" mesh should be split into its own smoothing groups. Programs like Akeytsu don't seem to be using smoothing groups, instead they're reading the actual vertex normals. But, the catch is, sometimes they're stored per polygon vertex. Which means, for a vertex to have more than one vertex normal, it needs to be split. Because, as you know, most game engines store their normals per vertex. So, Akeytsu is probably splitting up their mesh too, you just don't realize it.