5.5 Static Mesh Import Pipeline Regression

This question was created in reference to: [5.5 FBX static mesh import pipeline [Content removed]

This post references the first post because this problem was not discovered till now. I think it was masked because the issue appears to be that it is using the pivots of the objects in the scene and subsequently repositioning them to the origin to create the resulting imported mesh, which didn’t show up before because my previous use case had a shared pivot position.

So for example I can import the attached FBX into our old 4.25 project with the combinemeshes option to true and it looks like this:

[Image Removed]

and when I Import the exact same FBX into our 5.5 project with the combinemeshes option to true it ends up like this:

[Image Removed]The problem is that it is supposed to retain their relative position to the scene origin, not reposition them.

Also regarding the original thread, the respondent said: “I will come back to you next week with more details.” but that never happened and the thread closed, but from that issues 2 and 3 are still affecting us, so just some advice pointer on where to fix that in the code would be helpful cause we are going to have to fix it locally since its a persistent issue for us.

Update:

I ran into yet another regression. The same FBX can be used to repro it as well.

The regression is that the interchange fbx importer is doing some kind of silent ‘optimization’ by stripping out UV channels that have no mapped data, subsequently decrementing the index of subsequent UV channels.

So for example on the FBX it’s data looks like this:[Image Removed]So as you can see channel 2 has no mapped data. When imported into UE 5.5 it gets stripped and the resulting mesh then only has 3 UV channels. While if the same FBX is imported into UE 4.25 (or a whichever was the last UE5 version that was still using the old importer) it correctly imports as 4 UV channels.

It is not useful for the importer to unilaterally decide that it can ‘optimize’ that, standardized setups expect things to be in the expected index, not silently strip needed data with no option to opt out of that behavior.

Steps to Reproduce
The attached FBX file can be used to repro the problem.

Import the FBX with the import setting bCombineStaticMeshes set to true

Note how the separate objects in the FBX scene are now overlapping each other in the imported model.

This is incorrect behavior and not how it behaved before the Interchange pipeline was put into use.

Hi Clifton,

My apologies for not following up sooner on this issue and thanks for the detailed report.

I opened a ticket to track the resolution of your issue: UE-274316. Note that it may take a couple of days before the link is operational.

Thanks for your patience.

Regards,

Jean-Luc

Hi Clifton,

Thanks for the update. I added this information to the ticket.

It looks like I did not give you correct link to the ticket: UE-274316. Note that it is still not operational. I am looking into that.

Regards,

Jean-Luc

Hi Clifton,

The link is not operational. But we have not had time to look it yet.

Thanks for your patience.

Regards,

Jean-Luc

Ok, btw I figured out workarounds for both these issues, the UV issue can obviously be avoided by putting data into the channel, while the way to avoid the other issue is to reset the xform on the objects when their pivots are at the shared position, then I can move their pivots again and export and it uses the xform pivot instead of the regular pivots.

I would still prefer the original behavior though rather than having to do these extra steps, so I’m interested in fixing it locally, any advice/pointer on that would be helpful.

“I am looking into that.”

Any update on that?