We are using Rhinoceros 8 (SR32) with a Lab license for our students. When they try to render, the Rhino render window appears, but a message saying “Loading render kernels (may take a few minutes the first time)” is displayed, and a black image appears. After that, it takes several minutes to load, and then the rendering finishes in a few seconds.
I supposed this was only an initial issue, but when they tried rendering again, the “Loading render kernels (may take a few minutes the first time)” message appeared once more, and the rendering process is extremely slow. This issue happens every time .
PC runs Windows 11 Pro (25H2), has an Intel Core i5-12400 CPU, 32GB of RAM, and an NVIDIA GeForce RTX 4060 GPU (8GB of memory) with the latest drivers installed.
NVIDIA GeForce RTX 4060 already compiled (green dot is shown).
Since it works normally with local accounts on Windows, but this issue occurs with a student account that uses folder redirection, I suspect the compiled kernels are not being written or loaded correctly.
Is my assumption that Rhino cannot handle a UNC path like \\server\folder$\xxxx\AppData\Roaming, set by the environment variable %APPDATA%, correct?
Because using folder redirection is a requirement for student accounts, I cannot simply switch to a local account as a solution.
This has to do with where cycles stores its compiled kernels. It may be worthwhile to try setting these two environment variables to a path that is local:
CYCLES_SHADER_PATH CYCLES_KERNEL_PATH
It looks like this is an undocumented path that the renderer (cycles) uses to store compiled kernels.
I don’t believe RhinoCycles uses these at all. These would be used if a user did dynamic kernel compilation with nvcc.exe, but IIRC we always default to pre-built kernels.
@hira couldn’t the lab map the UNC path to a drive, and then set %APPDATA% to that?
I used net use to map a drive to the UNC path \\server\folder$\xxxx\AppData\Roaming. Next, I used the Command Prompt to change the %APPDATA% environment variable to point to that drive. When I launched Rhino from the Command Prompt, Cycles no longer attempted to load render kernels every time (I verified that the %APPDATA% had been updated correctly using Process Explorer).
However, it appeared that Rhino was attempting to write log files and other data to the local directory c:\users\xxxx\appdata\roaming rather than to the network folder specified by the %APPDATA% (which is not the behavior I expected) .
In any case, since I am not an expert in application development, I have decided to give up struggling to fix this problem further and change the %APPDATA% points from the file server to the local path c:\users\xxxx\AppData\Roaming.
Thank you for your advice.
I hope that the next version of Rhino will handle UNC paths correctly.
I see you are more than capable of figuring out stuff, but just for the sake of thread info completeness, an option is to render on the CPU and then no kernels are needed to be compiled.
When I last touched RhinoCycles code (January 2026) determining location where to write data to was done with the Rhino-provided PlugIn.SettingsDirectory property:
So whatever Rhino core does to determine that folder is what is being used. My recollection is that it is %APPDATA%. I think you need to explicitly move the location for it. I think something like this:
- Open File Explorer.
- Navigate to: C:\Users\<username>\AppData
- Right-click Roaming → Properties.
- Open the Location tab.
- Click Move....
- Choose your desired folder (for example, D:\AppData\Roaming).
- Apply the change and allow Windows to move existing files.
- Sign out and back in.
But that is from memory, and I’m not sure how well that would work on a multi-user system with drive-mapped UNC paths.
Anyway, lets hope current devs can improve UNC path handling - something that probably should happen in a core part.
The issue seems to be that CUDA_CACHE_PATH is, by default, pointing to %APPDATA%\NVIDIA\ComputeCache, which we already know is not getting resolved properly. If you can set CUDA_CACHE_PATH to point to a local directory, the problem should go away.
I’m looking into fixing this in a future release, but still unclear exactly how and for what Rhino version.
In my lab, we have already stopped using folder redirection for the Roaming directory and switched to using the local path c:\users\xxxx\AppData\roaming.
Thank you for the useful information.
I did a lot of search before posting this thread, but I couldn’t find any information regarding the CUDA_CACHE_PATH issue.
I hope the information in this thread will be of help to other users.