I was able to confirm that the local Nucleus Service was successfully linked.（But I can access the local Nucleus server by opening the folder view through houdini and I can create folders normally）
I have also tried running houdini with an administrator account (although I don’t think this method is relevant) and still can’t save to disk.
And I’ve also tried it with Unreal Engine 5.2, and I can access the local Omniverse server and read and write content normally.
It is normal if the usd is saved locally. And in houdini, after creating omni linker, when I select usd, I can see the files on the local server normally but Houdini can’t read them.
Nucleus Service Version：2023.1.0
System： WIndows 11
Houdini Version ：19.5.640
Houdini Connector Version：102.4.0
I have the same issue when trying to export to the localhost.
Is there a way to change the Localhost file location on windows, from “Documents” to somewhere else?
I am assigning a Data Path for Nucleus upon installation but my project folder is created in “Documents/Omniverse”.
@canned-planet are you getting the exact Houdini DSO Error message? and can you elaborate what you are trying to achieve by “changing the localhost file location from ‘Documents’ to somewhere else”?
Sorry, I am having the exact same problem as the OP when trying to write usd files from the Omniverse ROP.
Localhost files:
When I create a folder in the Nucleus Window Omniverse/localhost/Projects/* it will be created on my System Disk under “Documents/Omniverse/*” no matter what the Data Path for Nucleus is set to during installation.
When I save a Hip file using the localhost shortcut in Houdini, it will be written there.
I want my Data on a separate drive and not on my system disc. How do I do that?
that sounds like a peculiar behavior because i do not see that on my end. so, i checked with one of the devs on the Nucleus team (on Discord) and this was his response:
Files and Folders stored within Nucleus are not re-created on the file system (akin to OneDrive or Dropbox). The files are encapsulated and stored within the data path set within Launcher and the folder structure is stored within it’s database with pointers to the files. There is no correlation between folders created within Nucleus to folders on the Windows or Linux filesystem.
the reason why i asked about OneDrive is because i’ve seen an issue where OneDrive redirects the file through a OneDrive folder that would otherwise be going directly into a OV folder; thus, creating problem during connection/access to backend.
is it possible for you to do a screen recording of your export process showing both Documents and Houdini side by side (using a primitive in an empty scene)?
there doesn’t seem to be many reports, if at all, of OV connector export issue on the SideFX’s forum. not to say it doesn’t happen because you and another are clearly experiencing some odd behavior, but sounds like it could be an isolated incident. i am hoping your recording can demonstrate the steps for the devs to repro the issue if not pinpointing the problem from the getgo.
Hey Simplychenable,
thanks for your efforts to help clearing this up.
There is definitely something weird going on. The folder inside the Windows/Documents directory seems to be created by the connector HDA, not by Nucleus. After a fresh install of Nucleus and all folders deleted, the folder appears the moment I run Houdini with the connector installed.
I’ve attached a screenshot, showing the folders in Documents and the folder in localhost.
Note that the contents are the same except for the subfolders /Test and /backup.
I understand that Nucleus installs it’s own filesystem accessible only through the Nucleus browser. Is that correct? I was searching for the physical location on my drive for the files I saved to the localhost path from inside Houdini, that’s how I stumbled over the folder in documents.
This all seems very convoluted to me. It may connect to the other problem I described in this thread:
I just tried to save a fresh scene using the ov save hip button. and it shows up in the Nucleus browser and the windows/documents/Omniverse folder. So the two are definitely connected.
Is this perhaps why the ROP has trouble creating folders during export?
I have 19.5.640 because of Redshift.
I will try the new Production build, but I have so many issues right now with Create that this might take a while. Tutorial videos and Docs seem to be not up to date in many cases. It is very hard to trouble shoot.
Apropos safe to assume…
I assumed that the OV launcher would automatically install the latest version of Create. I was wrong.
I just checked and it turned out I had 2022.3.3 installed and the latest version is 2023.1.1…
Updating now.
This is one of the things that make my head shake for hours… ;)
not sure if it’s the root of the problem, but it’s always good to make sure you are using the latest and greatest. looking at other related threads on the forum, seems like there were others having better luck on Windows 10 😥
I totally agree, although WIndows 10 is not the latest version either…
At the Moment it is more a matter of finding out in which part of the chain the issues actually happen. There are several moving parts here.
First I need to make sure that Create itself is working properly. For example Ctrl-Z was not working for me. Now I found out, that Create is internally not adapting to my German keyboard layout, set in Windows. Things like that…
And of course I have trouble saving USD files to my NAS, due to permission issues…
