Quixel Bridge integration in UE5 is broken


it appears that the Bridge Integration in UE5 is just broken:

1, When I specify exactly the same local assets path as in the external Bridge app, the integrated Bridge won’t find the assets that were already downloaded with the external Bridge.

2, The download and channel options are completely missing. How do I set up channel packing?!

3, Resolution levels are renamed to Low/Medium/High. Come on! We are not children, we understand numbers and knowing actual resolution gives us more information.

4, Once surface is imported into the project, the generated material instance often has no parent material assigned:

5, Despite new integrated Bridge not having any packing options, the surfaces come already prepacked in a “ORDp” format. Why?

When it’s integrated in the actual engine, why would you not pack the channels in order which honors the Unreal’s PBR material slot order?

I sort of understood (or rather tolerated) controversial channel order when Megascans were pretending to be engine agnostic, but now, when they are flat out integrated right in the engine, it just does not make any sense to pack the channels in an order which inevitably ends up with ugly crossed material node connections.

6, When you download the incorrect resolution (because resolutions were renamed to quality levels) and proceed to find the material in your local library, you can fix the artificially created mistake by just downloading the larger resolution from there:

You actually need to go back to home section and find the exact material (among the hundreds of materials) again to actually be able to download the proper resolution.

While most of the UE5 improvements are a step forward, this Bridge integration is a big step back, exaggerated with the fact that the external Bridge app just flat out doesn’t work with UE5.

I know UE5 is still EA, but please at least update the external Bridge app to support it until the integrated one reaches at least the most basic of usability standards.


To add to that. With Nanite I want super high quality mesh with 4K textures.
But the new Bridge integration bundles texture size and mesh size…

Hi guys,

For assistance, you’ll need to write in to support@quixel.com so one of my agents can help you. Be sure to include everything from this post and any other relevant data so we can help as best as practicable.

Quixel Community Support Lead

In 90%+ of the cases, the response is always “We may fix it sometime in unspecified future”. There are 1-2 year old bugs/issues that still haven’t been addressed. So it’s very difficult to have motivation to spend time putting together elaborate support requests.


I have the same issue like you have in 4 point. I am trying to download object from bridge and materials aren’t working. Mesh is working properly, it downloads but it has defualt grey texture. Material instance looks empty. How do I fix that?

Same problem here, Bridge in UE5 stucks.
I’m trying to solve the problem using the standalone Bridge then exporting and reimporting into ue5. I cant see any other ways.

i found a solution to the texture problem. It looked like the mspresets folder’s content has changed from ue4 to ue5. so the wrong content gets migrated if you already had quixel assets before you migrating the project to ue5.
The way i fixed it is by deleting megascans folder in ue5 and mspresets folder in windows directory. then a clean/updated mspresets folder gets made with the first quixel download.

if you already have a ton of quixel content you want to keep in your project. I am sorry. I don’t know a solution that keeps the assets you already had in ue4.

1 Like

Agree with the first post. ORDp doesnt make much sense especially for materials with metal present. No metalness there. And who needs displacement on meshes especitally with nanite? This makes sense only for terrain materials. Export must be customizable. Currently this bridge plugin is useless.

I suspect the displacement channel is a hint of what’s to come in future for virtualized geometry, so it may be useful. My remark was more along the lines of the channel order being frustrating because it doesn’t mirror the material node input slot order, so you get ugly crossed lines.

That’d be fine if these textures were supposed to be used not just in the Unreal Engine, but since they are already in the form of an actual .uasset files, it’s obvious they are meant just for the UE, and in that case, having ugly input/output order resulting in ugly crossed line graphs just doesn’t make any sense.

I think whole nanite thing was made exacly because of getting rid of displacement and parallax techniques, because there is lots of issues connected to them (shadows, collisions, relief…). Just brute forcing it with geometry makes everything much simplier and probably even performant (and you save some memory by not needing height textures).

1 Like

I like to stay positive, and think that there’s some reason displacement channel remains there, for some future enhancement of the asset quality (Since after all, Quixel probably coordinates their efforts with Epic when they are now under it). For example something, which would dynamically subdivide the triangles even above the original mesh density when camera is up close to the asset and translate vertices of those triangles based on the displacement texture channel.

While nanite meshes are very high poly, their textures are still denser than their topology (otherwise, we could just straight up give up on textures and store PBR data in vertex channels for megascans :slight_smile: ), so this could provide some extra closeup quality boost. And since Nanite is very good at rapidly reducing the mesh topology on the fly in realtime, I can imagine it could be equally as performant in the other direction, increasing topology density on the fly. This would also make sense as a replacement for the now deprecated displacement tessellation feature.

1 Like

You got a point. But generally displacement on 3D objects is problematic, so that whats nanite for. And for 2D surfaces like wall you can still use paralax oclusion mapping, which is usually enough. There is not much cases where you really need true displacement and in these cases nanite geometry should be enough. For micro detail you can always use shared normal map.

I also think, that one of reasons why to use nanite (very high poly meshes) is saving of memory. Instead of individualized normal maps (and other textures), you can have geometry and you use shared normal map for micro detail, some albedo and maybe individualized color tint (cavity, etc…). Using such approach you can save huge ammount of memory. Typical use case is rocks. You can also make some automaterials using just baked cavity (and shared albedo/normals…), or on case of denser mesh vertex colors. It does not cover all cases, but by some clever asset design you can really save tremendous texture resources.

I am more into the engine source code than the use of the Bridge plugin. I therefore as Quixel support about the reasons for this. Here is their public answer
Are assets downloaded from the Bridge Desktop app available in Bridge for Unreal Engine 5?

My view is coming to UE5, with a little past background in Quixel. I have carried out the tutorial for UE5, but not for UE5 integration. I built the UE4 plugin code in UE5 and used them simply does not work, because as explained

UE5 serves assets in Uasset format

So even when the UE4 plugin has been made to work in UE5 it can as it says read “the Bridge desktop app only serves assets in source format”.

I cannot find a way to convert the UE4 source in getting it in UE5, in the required format as I cannot write Blueprint code only C++.

IMHO If anything we should concentrate on making an Exporter from UE5

Hi All,
I am not sure if this will solve your problem but just trying to tell everyone there is a new Epic Launcher based update described in

Quixel Bridge 21.0.4 Update to Unreal 5.0 EA2 Epic Launcher Binary version