Hello, I’m setting up a live session between Omniverse composer and Unreal with localhost. I used ParaView example can.e (exodus) file for testing two-way sync. Here are my steps:
Unreal Engine 5.3 and Composer 2023.2.5 on Windows
Create a live session in Omniverse
Add Omniverse actor in Unreal and join the live session
All the functions, including translate, scale, copy, and delete, worked fine except materials. The 3D model is missing materials in Unreal. Is there any steps I missed?
Yes the materials are very tricky. Especially because you are using the super old version 2023.2.5 on Launcher. The new version is now up to Kit 107. Also we do not technically support UE 5.3. I think we stopped at 5.0.
What about the other way around? If you create a material in Omniverse, does it show up in UE?
To be honest you are always better off getting your geometry into Omniverse first, without materials, and then applying materials to it, inside of Omniverse. Our material workflow there is very very easy and of course all the materials work perfectly. Just open our material library in Composer.
Hi Richard3D, thank you for your reply. Our goal is to set up a live session among ParaView, Omniverse, and Unreal, so that we can visualize exodus files in Unreal in real-time.
ParaView import exodus file with rendering and animation
Open View in Omniverse app from ParaView which starts a Composer app from Launcher. We can switch it to a newer version Kit107 if it’s possible.
Composer app starts a live session on localhost
Unreal joins the live session.
So far, the connection can be successfully set up. The geometry of exodus file is transferred correctly among three software, but material is missing in Unreal. Do you think this workflow is feasible? We also tried import USD locally without live session in Unreal. The example assets from Omniverse works fine in Unreal, but the ParaView 3D model doesn’t have any materials. Any suggestions?
So I am curious, why use Omniverse then? Just cut that out and go from Paraview to Unreal. Better still just export Exodus files to something Unreal can read. Is it not better to cut down on the amount of apps and just be as direct as possible? Or better still, cut out Unreal and do whatever real-time work you are trying to do in Omniverse.
The exodus data lost volume information when we exported it to FBX for Unreal and we also would like to access it’s field values with user interaction. Our goal is to create a VR app that can do:
Develop a game-like application (Unreal or Unity)
Customized VR user interaction
Customized UI where users can select what field value they would like to visualize
Utilize ParaView tools (e.g. slice tool)
Utilize ML models in the app
Most of those can be done in Omniverse without Unreal, but we couldn’t find much documentation to get started with customized UI and VR interactions. We would love to use Omniverse by itself to achieve all the goals. If we can get you help, that will be great. We can set up a meeting to discuss all the questions if that works for you.
Well then we can help you with Omniverse for sure. We do a great deal of amazing VR / AR / XR. We can also customize the UI both 2D and 3D very well. So it would make sense to do this in Omniverse.
Not specifically no, sorry. I would think you are better off only export geometry and material assignment IDs and not the actual materials. You can always apply far better, more realistic materials in either Omniverse or Unreal. Ideally, and I have said this before, apply materials in the “final solution” software. Only import geometry. Not lights, not cameras, not materials.
Got it. Appreciate your help. Thank you, Richard. I guess I can try use the exported texture png from ParaView USD export and create a material in Unreal with that png.
Yes that would be a better way. Find the raw source path to the texture file and just create a fresh, clean material with it. You can probably write a script to take a texture path and make a material automatically.