Hi everybody,
I wanted to share my early experience learning Unreal Engine, with a focus on using Quixel Megascan assets. I ran into more problems than I expected - some that stopped my progress until I found a workaround, and others that just confused me.
I don’t work in game development, though I am a software developer. The issues I ran into are entirely the sorts of things that, in my professional life, would be easily resolved by a quick chat with a more experienced coworker, but I am flying solo here.
Hopefully my little narrative will help some future beginners. I would also love to hear from others what their workflow looks like for handling external assets.
For all of this, I am using Unreal Engine 4.26 and Quixel Bridge 2020.4.2
First: The Vanilla Approach, Exporting Directly from Quixel Bridge
I started with what looked like the easiest path: using the export feature built into the Quixel Bridge app. Using all default settings, I exported a 3d asset from Bridge to the Unreal Editor (the “Sandstone Canyon Rock,” chosen approximately at random).
I immediately ran into my first issue: a warning, “No smoothing group information was found in this FBX scene. Please make sure to enable the ‘Export Smoothing Groups’ option in the FBX Exporter plug-in before exporting the file. Even for tools that don’t support smoothing groups, the FBX Exporter will generate appropriate smoothing data at export-time so that correct vertex normals can be inferred while importing.”
As far as I can tell, Bridge has no such option. Some quick googling suggested I could just ignore this warning, but I was still unsure: should I just expect to get this warning every time I import some meshes? Does this mean my vertex normals are messed up? Is there any way to eliminate this warning? I decided to ignore and move on.
After adding the asset to a scene, the first time I tried to build lighting, I ran into a more serious problem: Object has wrapping UVs.
At first I thought this would be easy to resolve: I should be able to use the mesh editor to auto-generate correct light map UVs and place them into index 1 (where index 0 is the standard texture UV). However, this is where I got stuck: despite creating a new UV and being able to view that UV in the mesh editor, I couldn’t change the “Light Map Coordinate Index” for the mesh. If I typed 0 into the parameter, it would automatically jump back to zero.
I searched around for solutions to this problem, finding some old threads on this forum. I learned a mix of things, including that there was a similar-sounding engine bug in 4.24, but it should be fixed in the current version (I also tried 5.25, just in case, no luck), and that I could probably fix the problem by switching my LODing to None, which didn’t seem great. After banging my head against this for a while, I eventually noticed that there were no lightmap UVs for LOD1+, only for LOD0. If I swapped between each LOD in the mesh editor and generated a UV lightmap for each LOD (i.e. generated a UV at index 1), I could now change my Light Map Coordinate Index to 1. Success! I built lighting without error.
This ultimately made sense, though I was frustrated I didn’t get more feedback from the editor, or maybe I did but I just didn’t know where to look. I would like to have been told: “can’t change Light Map Coordinate Index - not all LODs have UVs at that Index”
Issue resolved, I was left with one last warning in the material viewer for my rock: “Warning: Roughness samples <path> as Linear Color” The warning was descriptively true, but I didn’t understand why this meritted a warning - Linear Color seemed like the right way to sample a roughness map, and the relevant texture was not tagged as sRGB. I still don’t understand what’s going on here.
Second: The Manual Approach, Importing Each Asset Individually
Mostly for my own education, I tried to reproduce the actor I ultimately assembled above by importing each component object: the mesh, albedo, roughness, and normal. I also created my own dead-simple material and dropped in the various assets.
This worked fine. I got the same “No smoothing group information” warning, but the light map UV had a slightly easier workflow: By importing just the LOD0 mesh, then generating a lightmap, then adding additional LODs in the mesh editor, I ended up with light map UVs for each LOD without having to click through each of them.
But the actor, once placed into the world, looked pretty messed up: It was substantially lighter than the first actor and the lighting looked off.
Investigating both, I realized that the normal map I got from the manual import differed importantly from the normal map I got when using the Bridge export feature: the Green channel had been reversed. This was easy to fix: either applying 1-x on the green channel in my material, or using the bridge-exported normal map, worked fine.
So, this problem was easy to fix, but I didn’t fully understand it - some googling suggested that inverting the green channel is a standard-ish part of 3d modeling workflows (I guess there isn’t a global consensus on implementing normal maps), so I moved on.
Now, my manually imported actor was still brighter than my Bridge-exported asset. Some investigation followed, and I realized this was because the Bridge created material was applying a non-zero metallic value (around 0.5). I don’t currently understand why the primary visible effect of increasing metallic was to darken this particular object, but I could reproduce the behavior exactly in my simple material, so it was definitely coming from the metallic value.
This didn’t leave me with a technical problem, just a bit of confusion - why default to a metallic value of ~0.5 for a rock? I don’t think this is the intended look of the asset, though I could be wrong.
Combining the Two: My Candidate Workflow
- Export from Quixel Bridge, but configure to only export the LOD0 mesh.
- Use my own master material.
- In the mesh editor, Generate a light map UV (source index 0, destination index 1), set my light map coordinate index to 1, and generate additional LODs.
And this works well. I still get a “No smoothing group information” warning on import, and a “Roughness samples <path> as Linear Color” warning when viewing my material.
I have a few questions for the community:
- Does my workflow seem reasonable, or am I missing something important? What does yours look like?
- Is there any way to resolve the warnings I get?
- Bridge downloads some large files that don’t seem to be used in either workflow: a .exr file, and normal maps for each LOD. Do I actually need these? How bad is it to use the same normal map for each LOD? (I don’t actually know how to change this, even if I wanted to).