Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrading meshes with mesh versioning tools yields different result than manually re-importing them. #84079

Closed
QbieShay opened this issue Oct 27, 2023 · 14 comments

Comments

@QbieShay
Copy link
Contributor

QbieShay commented Oct 27, 2023

Godot version

b662d23

System information

Fedora, RX 590

Issue description

I have a sphere mesh in the project that was likely generated in 3.x
Godot auto updated it, but the normals aren't correct.
Freshly importing it makes the issue disappear.

It feels like Godot doesn't reimport/regenerate the mesh resource if it's already present in the .godot cache?

Screenshot from 2023-10-27 22-39-28
image

Steps to reproduce

Download mrp, observe scene.

Note that the two glb files are the same identical file, just duplicated.

Minimal reproduction project

FresnelBroken.zip

@AThousandShips
Copy link
Member

Seems this wasn't fully fixed, or some other weirdness is going on:

@clayjohn
Copy link
Member

If this is the same mesh from #84026, then the normals are broken in 4.1 as well. So this might not be a regression

@QbieShay
Copy link
Contributor Author

QbieShay commented Oct 27, 2023

I'm not sure it's the same mesh. I don't thhink so. But it's probably a 3.x mesh

When i tried to use it the engine said " i need to reimport" and then it started being striped.

@TokisanGames
Copy link
Contributor

TokisanGames commented Oct 28, 2023

This is a duplicate of #63550 if coming from 3.x or #64854 if coming from an early 4.0 alpha.

ArrayMesh is not a supported savable format. There is no accurate upgrade path from 3.x meshes (and there will never be one from early 4.0 alphas per lyuma), nor is there versioning information in the file. You can read about this discussion (eg 1, 2 ) and a proposal from Clayjohn that was never implemented in #64854.

Unfortunately, your saved .res is no longer valid. Your only good option is to reimport from the glb. A possible alternative if coming from an early 4.0 alpha is to export it as gltf and reimport but that gives 80% at best and only works if the problem is from octahedral compression.

@QbieShay
Copy link
Contributor Author

I'm puzzled that Godot knows that the file needs to be reimported, but at the same time it's not able to reimport it in the same way as if I put it in the project and reimported it manually. I don't understand the details of the importer though.

@TokisanGames
Copy link
Contributor

image

Did you save the ArrayMesh resource from the mesh object into these .res and .tres files? That was a common, best practice in GD3. If so, the GLBs are not being used at all only the .res files are.

The old .res/.tres arraymesh resource files are invalid. Though an upgrade path was never created, Calinou did at least document it.

The only thing to be done is delete the .res/.tres files. New recommended best practice is to inherit the scenes from the glb, and never clear that inheritance. If you clear it, the scene will save the disassociated ArrayMesh within itself. Never save the mesh resource to an external .res/.tres file either.

If you remove the inheritance from the glb, you're using Godot in an unsupported manner and subject to having your meshes broken at any time by core devs again. Juan said it "should not break within 3.x or within 4.x", but I've seen no documentation of an official policy, "should" is far from absolute, and devs have already broken the format 3 times in 2 years. No game studio business can rely on that uncertainty.

@QbieShay
Copy link
Contributor Author

QbieShay commented Oct 28, 2023

I can't inherit when I need to put the meshes in the particle system, i need mesh resources.

I have currently moved onto obj files for VFX, works great, but i still have older meshes in glb + external mesh.

@TokisanGames
Copy link
Contributor

Sorry, I don't make the policies. I've been a vocal proponent of sanity, but my efforts have fallen on deaf ears.

My team and I have had to reimport nearly a thousand meshes twice because of core dev choices. In 3.x we deleted the glbs and only used .res. So when we found out they were not going to support their own native format, we had to go through the entire asset pipeline: source -> DCC -> GLB -> Godot pipeline. Their decisions have cost us hundreds of man hours and delayed us several months.

You can save to ArrayMesh but you run the risk of core devs breaking your game in the future. 3 times is far too many for me. Storing both .obj and .res would save you from going through the whole pipeline in the case of that event. Depends on your risk tolerance.

We've confirmed this ticket is a duplicate.

@QbieShay
Copy link
Contributor Author

QbieShay commented Oct 28, 2023

Of note I haven't removed the source glb files, they're still there side-to-side. Seems like a different workflow to me?

This isn't "the mesh formats are incompatible" this is a "a manual operation that is supposed to do the same thing as the automatic one has a different result"

@QbieShay QbieShay changed the title Upgraded meshes' normals aren't correct Upgrading meshes with mesh versioning tools yields different result than manually re-importing them. Oct 28, 2023
@QbieShay
Copy link
Contributor Author

I have updated the issue to reflect better what this bug report is about. Sorry for the lack of clarity.

@TokisanGames
Copy link
Contributor

TokisanGames commented Oct 28, 2023

Of note I haven't removed the source glb files, they're still there side-to-side. Seems like a different workflow to me?
This isn't "the mesh formats are incompatible" this is a "a manual operation that is supposed to do the same thing as the automatic one has a different result"

Please look at the contents of your scene files and material resource. Are the mesh resources linked to a .glb file or a .res file? If the former, then this is indeed a different issue and I'll step out of the conversation and edit my comments as they no longer apply.

If the later and your scenes are linked to an ArrayMesh .res, everything I said applies and this is a duplicate. There is no "mesh versioning tool" or mesh upgrade process for 3.x ArrayMesh. It is an unsupported storage format.

ps. I did look and see it is linked to the .res files.

[ext_resource type="ArrayMesh" uid="uid://c8f7k7sitgmr2" path="res://Sphere.res" id="3_wbpcl"]
[ext_resource type="ArrayMesh" uid="uid://de8paag8pcdpt" path="res://SphereFreshImport.res" id="4_tja2j"]

It's a duplicate because you stated this, and your scene is linked to it. Presumably Sphere.res is the 3.x format.

But it's probably a 3.x mesh

The 4.2 mesh upgrade PRs in development are for 4.0a15-4.1.2 ArrayMeshes only (confirmed by clayjon). In the tickets I mentioned, it was made clear there would be no ArrayMesh upgrades from before 4.0a15 or 3.x.

@QbieShay
Copy link
Contributor Author

They are bound to res files, but these res files are external and generated by the glb. So reimporting a glb should override the res file (if you look at the mesh tab of the import popup, the mes is set as "save to file").

@TokisanGames
Copy link
Contributor

I can't actually open up your MRP in gd4.2 beta 3, or any version at all. The scene is corrupt.

However, I do see the Sphere.glb is set to save externally as res://ShieldPack/Meshes/Sphere.res, which doesn't exist in your MRP.

When I double click Sphere.res it displays as corrupt in the inspector. This file is what your scene is linked to and is most likely from 3.x.

If Sphere.glb is set to save externally as res://Sphere.res then I reimport, then doubleclick Sphere.res it updated it and looks fine in the inspector. (However, the shadow mesh doesn't display in the inspector as it does for SphereFreshImport.res. But it seems to work the same as the other as it switches LODs on the shadows.)

So sorry to sound like a broken record, but duplicate because of the 3.x mesh, and no bug on the importer just a misconfigured setting.

@QbieShay
Copy link
Contributor Author

Ahhh. I understand now. I didn't notice the path was wrong. Fixing the path seems to fix the mesh.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants