godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
87.17k stars 19.59k forks source link

4.2 imported models have broken normals #85406

Closed Go-Ba closed 5 months ago

Go-Ba commented 8 months ago

Godot version

v4.2.beta6.official [64150060f]

System information

Godot v4.2.beta6 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 31.0.15.3623) - AMD Ryzen 5 2600X Six-Core Processor (12 Threads)

Issue description

When I import a model it will have anywhere from slightly to very messed up normals on surfaces which are completely flat. This happens both when importing the model into 4.2 or when using the automatic upgrade from 4.1 to 4.2.

The models show completely expected normals in blender, godot 4.1, and other 3D model viewers. They only get messed up specifically in godot 4.2. I tried pretty much every export option in blender and every import option within godot and could not find anything that would change this behaviour.

Obviously wrong normals

image

Other versions

image

Blender shows regular normals

image

Steps to reproduce

Import a .glb model with a complex flat face into a 4.2beta version and it may end up having messed up normals.

Minimal reproduction project

4.2b6_gltf_import_test_project.zip ProblematicModel.zip DebugNormalsShader.zip

akien-mga commented 8 months ago

I can confirm the issue on 4.2-rc2 on Linux (AMD Radeon RX Vega M).

On the other hand I also see normal issues on 4.1.3-stable, albeit not as bad, but still not all correct: image

I also see these normal issues on https://modelviewer.dev/editor/ image

So I assume these are not the main problem to focus on, but the difference seen between 4.1.3 / Modelviewer and 4.2-rc2.

clayjohn commented 8 months ago

Early testing shows that the issue goes away when force_disabled_compression is used in the import settings.

I'll see if I can find the root cause of the normal corruption though.

Another note: This is different than issues like https://github.com/godotengine/godot/issues/84270. While this model contains invalid UVs (for generating tangents), the issue is present even when "ensure tangents" is disabled. So the issue likely doesn't have to do with tangent generation.

clayjohn commented 8 months ago

Just did some more investigating. It turns out this issue comes from the original .GLB having bogus tangents.

I imported the model into blender and then exported it without tangents and it looks correct when using compression (as it uses the generated tangents provided by Godot).

This is a difficult situation as technically the model itself is broken, its just that Godot didn't care before. Now Godot is more sensitive to broken meshes (which is why we have the force_disable_compression option in the import settings.

I have re-labelled this issue as a documentation issue as we need to work on communicating to users that the option is there to disable compression and potentially fix issues with broken models.

In the future, we need to investigate some other form of analysis or warning. For example, we could test a few tangents on import and warn users if bogus tangents are detected. But doing so would come with a performance cost and may not be foolproof, so it is something we need to discuss and investigate further.

Go-Ba commented 8 months ago

Originally when trying to fix this issue I was going through different export and import settings and somehow overlooked the "force disable compression"

I think that's because unlike other options in the import, it is a negatively stated option that is toggled off by default instead of a positively stated option toggled on by default like the others in the list. Compression is something that the engine is doing to the model which I want to turn off so toggling an option on is less intuitive. Changing it to something like "Enable Compression" which is on by default would be an improvement IMO. It would also shorten the name so it is easier to read on thinner windows.

image Even though it is still cut off, I can much more easily intuit what this option does without knowing about it previously. This would make it easier for people to find the solution when their model looks broken and they just scan the import options.


When it comes to exports, what blender export option did you use to disabled tangents? I have this option unchecked and it is like that by default, but I still get the issue. Is it a different export option? image What did work for me was taking the model into blender, doing a smart UV project and then exporting it. Seems to look fine even with force_disable_compression disabled. To be perfectly honest, I had no idea prior to this that the UV projection would affect rendering of normals in this way

clayjohn commented 8 months ago

Changing it to something like "Enable Compression" which is on by default would be an improvement IMO. It would also shorten the name so it is easier to read on thinner windows.

I agree, we were just discussing that in the contributors chat earlier today. Most users are only seeing "force disab..." which is super unhelpful.

When it comes to exports, what blender export option did you use to disabled tangents?

I just ensured that the "Tangents" option was unchecked, then I exported to GLB and imported it into Godot. Using Blender 3.4.1 if it matters.

To be perfectly honest, I had no idea prior to this that the UV projection would affect rendering of normals in this way

Which is totally fair. The fact that tangents now matter is a new change that came in 4.2. It's only for compressed meshes. Our compression scheme requires valid tangents in order to compress normals. We added the "force disable compression" option knowing that there will be meshes floating around with broken tangents.

To me, a proper solution here is going to require making it easier to identify this issue and resolve it (the resolution will be to check a box in the import settings). We just need to somehow communicate effectively to users without spamming them with errors.

killercrash commented 6 months ago

Hi, I was wondering if my issue is related to this issue :) I believe things were fine on 4.1, and they are fine when I drop them in Unity.

ae_house_05 tscn - Godot Engine ae_house_05 tscn - normal - Godot Engine house_09 tscn - Godot Engine house_09 tscn - normal buffer - Godot Engine

I've been messing with import settings, disabling compression and tangent, but nothing has changed. I'm a noob at 3d modeling, so I might not have spotted a problem on the models. I would love to know if I just need to wait for a godot update or if I should retake things in Blender. (I'm bad at it, so I bought those .fbx of houses a long time ago, but I can manage to work on a fix if necessary.)

Thanks for your time and dedication!

System information Godot v4.2.1 - Windows 10 Pro 64-bit - 64.0 Go Dual-Channel DDR4 @ 1070MHz - Vulkan (Forward+) - 3071MB NVIDIA GeForce GTX 1080 Ti (EVGA) (NVIDIA; 31.0.15.3734) - Intel Core i7 8700K @ 3.70GHz

ijidau commented 5 months ago

@killercrash your normals seem flipped, rather than this specific compression related issue. The blue surfaces on the apartment block normals are forward facing, but the red are backward facing. You need to check your normals in your 3d program to verify there is no issue there first.

ijidau commented 5 months ago

I can confirm I have exactly the same issue as the OP. In my own tests, the compression seems to wreck the normals. It took a very long time to find this problem, and as mentioned, the toggle for compression is expressed in the opposite way than expected. I'm fairly sure I also would have tried turning it off if it had been enabled to indicate compression was active.

Calinou commented 5 months ago

the toggle for compression is expressed in the opposite way than expected.

It should be possible to rename the option and invert its behavior as long as we have a compatibility handler to port over the old value on existing resources.

killercrash commented 5 months ago

@ijidau I've tried to check the .fbx in Blender and the normals looks ok apparently :/

normal_1 normal_2

ijidau commented 5 months ago

@killercrash you've got quite a few overlapping edges in your mesh where I've marked yellow. These will cause the shading issues you are seeing.

overlapping_edges

ijidau commented 5 months ago

@killercrash actually I've just spotted some more. Check your mesh carefully, as you have connected edges in some strange ways that cause them to overlap. Also double check you haven't got any duplicated faces, edges, verts etc. A bit of mesh cleanup should solve your problems.