Hello. I am adapting the online synthetic data generation tutorial to my own needs. I’ve stripped out the shapenet code and at this stage I am only trying to get my USDs to appear properly within the scene. I am able to load in the USD files to isaac sim directly by just dragging and dropping from the content pane. However, when trying to use create_prim, a warning is logged to the console:
2022-03-23 21:57:05 [9,883ms] [Warning] [omni.usd] Warning: in _BuildHdMaterialNetworkFromTerminal at line 517 of /buildAgent/work/ca6c508eae419cf8/USD/pxr/usdImaging/usdImaging/materialAdapter.cpp -- Invalid info:id /home/djones/.../MI_Box_02_Wet.mdl node: /World/Asset/mesh0/Looks/MI_Box_02_Wet/MI_Box_02_Wet
...
2022-03-23 21:57:05 [9,883ms] [Warning] [omni.hydra] hydra::material(0x55d9df296690/) something wrong in UpdateMaterial(), fallback to deprecated or failed material.
waiting for materials to load...
done
Am I missing something here? Is there some other way to do this besides create_prim?
I figured this out. I made a small mistake concerning how to run code correctly in the packaged environment which is detailed here.
One note that I would make is that it’s very inconvenient/disorganized to have to run my scripts from within isaac sim’s package installation directory for my workflow. It seems like (for most users) it would be as easy as referencing $XDG_DATA_HOME during installation, and then providing a simple command on the path to source isaac sim’s libraries. You can simply replace line 2 of setup_python_env.sh:
#SCRIPT_DIR="$(dirname "${BASH_SOURCE}")" # old line
SCRIPT_DIR="/home/$USER/.local/share/ov/pkg/isaac_sim-2021.2.1"
# you can do this in setup_conda_env.sh as well
Now you can source this file once and then work out of a more standard working environment. I’m unsure if this goes against the typical use-case planned out by nvidia, but in any case this is a simple work around to keep my project structure a little cleaner.
I am getting the same issue on the converted Shapenet objects
Can you provide a little more detail on what the issue was/how you fixed it?
I can provide some further details around my scenario. I was really interested in having my own project structure that wasn’t inside of isaac sim’s pkg installation directory. I tried running ./setup_conda_env.sh inside of the installation directory and then moving to my project folder and performing tasks but that didn’t work. That script sets a number of important environment variables in your terminal session that help point the python libraries to Isaac Sim’s installation directory.
My debug process started by going to isaac sim (launched through omniverse) and running code snippets in the built-in script editor. This is kind of a pain, but I was able to confirm that everything worked. I then tried running ./python.sh /path/to/my/script.py from within isaac sim’s installation folder (as detailed in the docs) and that worked as well.
I opened up the setup_conda_env.sh file and added some echo statements to see what was going on and I realized that it was using relative paths to set the location of SCRIPT_DIR. This means that if you try to run code somewhere else that uses isaac sim, the environment variables won’t correspond to the correct location.
To me, it seems like they should have made this a little more flexible for the end user. The workaround I describe in my previous post is fairly straightforward I think.
Hmm so if I am doing something like:
cd /home/user/.local/share/ov/pkg/isaac_sim-2021.2.1/
./python.sh /media/user/vol/project/main.py
To run my script would you expect me to be having the same issue?
It is weird because I have a collection of models for which I don’t get the error from another dataset but the Shapenet ones all seem to produce the error you reported above and fail to load their textures. As you said as well, adding them directly through the GUI is no problem at all - they load properly and no errors are produced.
It seems to me like the scripting interface is pretty fragile and very prone to errors that are difficult to debug/solve. Do you get any output in your terminal, e.g., warnings or errors? I find them to be at least somewhat indicative that I’ve made a mistake somewhere even if they don’t tell me what’s wrong.
One thing that comes to mind from my own experience thus far: the import statements are very unusual for a python API. If you’re following the replicator tutorials as I was, you’re responsible for starting the simulation and then importing the necessary modules at the right times/places. Studying the included scripts can help provide some clarity on how to import. I think the general rule of thumb seems to be “don’t import until you need it.” Especially limit yourself on loading in modules from omni.isaac.core before starting the simluation app.
Oh sorry if I wasn’t clear it is exactly the message you received:
2022-03-25 10:18:58 [6,902ms] [Warning] [omni.usd] Warning: in _BuildHdMaterialNetworkFromTerminal at line 517 of /buildAgent/work/ca6c508eae419cf8/USD/pxr/usdImaging/usdImaging/materialAdapter.cpp -- Invalid info:id /home/user/.local/share/ov/pkg/isaac_sim-2021.2.1/kit/mdl/core/Base/OmniPBR.mdl node: /World/Chairs/pos_x/Looks/material_5_24/material_5_24
2022-03-25 10:18:58 [6,902ms] [Warning] [omni.hydra] hydra::material(0xd318c20/) something wrong in UpdateMaterial(), fallback to deprecated or failed material.
I have been using the scripting API for about 6 months for this project and it is working with another set of models I have been using. The consequence of this error is that the materials don’t get loaded onto the object. So when capturing a render a default material is applied, yielding:
The same objects loaded in the GUI are fine, they are textured correctly.
Sorry I was hoping there would be some other odd output debug messages from the program. For my issues, there was a ton of other output that I initially dismissed as nuisance messages but then reconsidered once nothing was working quite right. Those messages eventually led me to realize that my environment was improperly configured.
What you’re saying definitely seems to rule out the possibilities that I am familiar with, especially since it works with other files and it works in the GUI, it’s hard to pin the blame on the assets or the code you’ve supplied. I was going to suggest that perhaps the asset was exported to USD with relative paths and then the exported USD was moved to a new location (this would mean that it now can’t find the referenced materials), but it seems like it would not work in the GUI if this was the case. You could verify that it can find the textures by looking at the properties pane (I suspect you’ve likely already checked that).
It’s frustrating how little information is exposed by this error message. I think it would be worthwhile for the development team to detail better debug procedures or expose more information to the end user.
1 Like
