• 3D

  • Mesh normals imported from Blender look wrong with every export type except obj

I have a model in blender, with normals correctly set up, as seen in the following picture:

When I export it in most formats (FBX, collada, better collada, escn gltf), I get a strange shading issue that seems to be related to incorrect normals:

What's even more strange, is that exporting the mesh as OBJ, and manually adding it to a MeshInstance looks different, like this:

Do you know of anything that might be causing this weird shading issue? It's not a deal breaker, as I can luckily still use obj for the mesh, but it's a bit cumbersome, especially since obj models get imported as meshes, not scenes, so I have to manually set up the scene myself.

Thanks in advance!

1 question. the pillars in the middle there, do they have caps?

2 question: have you checked for duplicate vertices? ¯\(ツ)/¯

3rd question: when exporting, in the options do you have it convert from quads to triangles? I have found that converting to triangles in the exporter settings can sometimes help.

(Also: welcome to the forums!)

TL;DR: Are there internal faces, might you have accidentally duplicated your mesh and did you try adjusting export/import settings.

Hi, thank you all for your time! =)

1) If by caps you mean if they're closed at the ends, they are (see the pic below). Otherwise I'm not sure about your question :S

2) I tried, and there seem to be none. Using the "merge by distance" option always reports "0 vertices removed"

3) I hadn't tried that. But it seems that didn't do the trick either. This is what it looks like when I export using the better collada plugin and triangulating the output:

I'm uploading the models, maybe this way it'll be easier to see what's going on :) You can find them here: https://drive.google.com/drive/folders/1aAj61Lenk_bEnlA3q-sVw8sfRE8I9us9

Try removing the internal faces(it might be throwing the normal calculations off), and yes that's what I meant.

@Megalomaniak I'm sorry. I'm not entirely sure what you mean by internal faces :sweat_smile: . Are you talking about the faces that are overlapping different parts of the mesh (as seen in my first pic)? Or internal as in back face (like in back face culling)?

Maybe there is nothing wrong. It just looks flat shaded to me.

I'm talking about the faces that are closing the ends as you said. They are inside of another part of the mesh. Though as @cybereality said, I think your mesh is just reflecting the sky colors the way it is because it's all flat shaded.

But if that shading is correct, how come I'm getting different results for obj?

I find it strange that two almost coplanar faces would reflect light that differently. The obj version looks way better to me.

Maybe understanding the difference between the two models will help me understand my issue. Is there any way I can show debug lines to look at the normals in Godot?

They might not be quite as co-planar after the triangulation that happens during rendering.

Try changing the lighting in Godot and see if that helps. You can try disabling the sky ambient light on the world environment and adding a simple directional light to test. Blender and Godot have default environmental light and they may not match up, so you can't compare renders exactly unless you customized the light and made them match.

Many thanks again for your input! But I must reiterate: I have an obj export of this mesh that looks perfectly fine in-game, the lighting of which matches what I can see in blender. So I don't think there's anything I can change on the geometry that would fix my issue.

Nevertheless, I've tried tweaking all the parameters I could find in the export settings, and also removed the caps at the top of the middle pieces, but nothing seems to do the trick.

I think it's a reasonable assumption to think some piece of the import/export pipeline is to blame, but I don't really know what else to try.

I've tried changed illumination settings around, and I haven't found a setup that fixes the problem. Take this shot as a comparison (first is the dae export, second the obj export), you can see the directional light as well.

There's also this one I took where I replaced the environment with a very basic one, with clear color (no sky), zero sky contribution (just in case), and white ambient light with a directional light, just to rule out the possibility that it's a sky reflection:

I see. Yeah, that definitely looks like a problem then.

Do you think I should open an issue on GitHub, then?

It is probably worth opening an issue, though a minimum replication project (or in this case, 3D file) would probably be needed to help debug what is going on. There is definitely something strange going on with the importer though, since the normals shouldn't be all wonky like that.

@TwistedTwigleg no problem, I'll upload the 3d files :+1:. Once I have some time I'll post the issue, then

@Megalomaniak I've tried glTF, FBX and the two collada exporters and they all seem have the same issue. Will make sure to include all the exported files in my example.

Again, thank you all for your time!

I just want to second the problem. My model uses a normal map (baked from a high poly version in blender) and looks absolutely fine in blender using Eevee as renderer. But in Godot the lighting is messed up and it looks alot like a normal problem. I am importing the model using gltf but it shows incorrect lighting no matter what I try (I even remodelled it 3 times which took alot of time since I remodelled the high poly version, too, and getting the baking right takes some time as well). Blender

Godot

Unfortunately for me this is a deal breaker as the complete model consists of multiple meshes (body and wheels and a semitrailer with another 6 wheels not shown here) and bones. I exported the body as obj but was not able to load it into the mesh instance. The mesh is shown in the inspector but not in the viewport. Importing in parts is not a viable workflow for my coming models.

@Setzer22 Please post a link to the github issue when you reported the problem.

I am open for any help offered and willing to help investigate the problem.