If I export a material from Unreal as MDL (with just a base color), then re-import it, the node graph becomes HUGE. If I then export that material and re-import, it becomes even larger and the materials look totally off with the following output log:
LogShaderCompilers: Display: /Engine/Generated/Material.ush(2426): fatal error: Too long source line
MaterialFloat Local6 = dot(MaterialFloat4(MaterialFloat3(MaterialFloat2(MaterialFloat4(1.00000000,0.00000000,0.00000000,0.00000000).r,MaterialFloat4(0.00000000,1.00000000,0.00000000,0.00000000).r),MaterialFloat4(0.00000000,0.00000000,1.00000000,0.00000000).r),MaterialFloat4(MaterialFloat3(MaterialFloat2(Local5.r,Local5.g),0.00000000),1.00000000).r),
Thank you for posting, I will bring your issue to the attention of the developers.
Thank you for your patience.
So, I’m not sure why you’re re-exporting a UE4 material that was translated into a UE4 material from an exported MDL, but we sure attempt to support it. I took this Blue material:
and exported it to MDL then imported it to a UE4 material and got this:
Sure… it’s not perfectly simple and pretty, but it works and the extra stuff is there because when we export we’re aligning classes of materials with different MDL templates, and you inevitably get extra stuff. I decided to export it again to MDL and reimport it again as a UE4 material and got this:
It’s still BLUE and it compiles! Yeah, I can see repetitions in the logic due to the repeated export/import/export/import. Just because… I decided to export it to MDL and reimport it again and got this:
Oh my gosh it’s still BLUE AND WORKING! I was honestly trying to repro your bug, but this was lots of fun.
In all seriousness, I can see that the export/import/export/import cycles add repetition due to the template methods we’re using. We don’t really intend for users to re-export an MDL that’s been imported, they shouldn’t have to. Once you see the MDL in the Omniverse folder, it exists in two states, the MDL and the transient UE4 material. If you intend to tweak materials after export we intend for you to parameterize them and change the parameters.
Can you tell me why your workflow requires this type of export/import cycling, and maybe we could figure out a different way that doesn’t break your material? Thank you very much for reporting, and I hope we can get to the bottom of the issue.
Could you please elaborate on “parameterize them and change the parameters.”?
I’m pretty new to MDL/USD and it’s been a steep learning curve. I’m trying to create a system where we can import or create materials in UE, export them and use them in, say, Maya. Then export from Maya, and import back into UE. Or simply edit in UE, publish them to a centralized server and let users reimport them somewhere else.
Referencing/layering is something else I need to implement but that’s another topic.
I haven’t seen any good examples of this in omniverse yet so if there are any resources besides the videos I’ve watched here please let me know. Totally let me know if I’m going on the wrong direction completely here. I’m currently writing custom scripts to handle all of this in pure USD but would love to use omniverse as a solution if possible as that would save a ton of dev time.
Alright, I’m excited to tell you that we can support this workflow. We’ve tried to make it so that when you edit the USD and MDL you know longer need to “export”, but instead you’re editing in-place. If you want to do heavy-lifting and really change the guts of a material that you’ve exported, that’s another matter that I’m not demonstrating here.
I will show demonstrate with screen shots these steps:
- Create a “parameterized” UE4 Material and Material Instance
- Apply them to a shaderball level in UE4 and export that as a USD stage (stage, meshes, lights, cameras, and materials)
- Open this USD stage with MDLs in Maya, Create, and UE4
- Live-edit the MDL material parameters in UE4 and Create and show that they update in Maya, UE4, and Create
- Make a material and material instance with parameters (so they don’t require a recompile in UE4 and MDL can make tweakable parameters):
- Here’s the level in UE4 before exporting it:
- I’ve exported it to Omniverse as a USD stage + MDL materials and opened it with live-sync enabled in Maya, UE4, and Create. I then went to UE4’s material instance editor and made the material’s Color Map Scale red:
- I went to Create and found some textures on the Nucleus server and modified the Color and Normal maps in the material:
There are two items that I found were an issue:
- The “Color Map Scale” parameter did not display in Hypershade in Maya. I’ll look into why that might be.
- When I attempted to change the Color Map in Maya, I could not browse the Nucleus server, and pasting an Omniverse URL into the dialog did not change the material.