OTOY Forums

DAZStudio.exe caused ACCESS_VIOLATION in module "C:\Windows\system32\nvcuda.dll" at 0033:00000000E1D5682A, cuD3D10GetDevices()+2879244 byte(s)

When are you getting that crash pls?

Paul

face_off wrote:When are you getting that crash pls?Paul

Sorry for the late reply!!!
I was pretty sure I had replied!

Anyway, my problem is something related to the the RAM.
The scene is composed only by G3 and a full sci-fi suit and the displacement maps are all TIF files (six files, 32mb each).
Changing the tif with jpgs solved the problem.

To be honest I didn't expect to encounter an issue like this.
I have 3 gtx980ti and 32 giga of RAM.
So, seems it's not enough to reserve 6gb from the system ram.

Anyway, my problem is something related to the the RAM.
The scene is composed only by G3 and a full sci-fi suit and the displacement maps are all TIF files (six files, 32mb each).
Changing the tif with jpgs solved the problem.

Not sure if you mean RAM or VRAM. You might be able to resolve the issue by changing the Out Of Core settings too. Regardless, this appears to be a general Octane or DAZStudio issue, rather than a plugin problem.

Paul

face_off wrote:Not sure if you mean RAM or VRAM. You might be able to resolve the issue by changing the Out Of Core settings too. Regardless, this appears to be a general Octane or DAZStudio issue, rather than a plugin problem.Paul

I meant RAM, system RAM.
So, 6gb of VRAM is not enough for a full scifi suit with 6 tif map
Yes, I use the OoC setting, but most of the time this does not solve the issue.
Sometimes the render starts and finishes without too many problems, but it seems like a gamble.
I even tried to use the slaves out of core memory (10gb!), but the problem is still there.

My guess is that the plug-in tries to do fit everything in the VRam and if it's not enough is unable to "shift" to the system ram and fails.

My guess is that the plug-in tries to do fit everything in the VRam and if it's not enough is unable to "shift" to the system ram and fails.

The Out of Core functionality it handled by Octane, not the plugin. So you should see the same behavior if you export to ORBX and open the file in Octane Standalone. The only difference would be the RAM the DazStudio is using to host the scene.

Paul

I have updated the installer at the top of this thread with:

3.4.4.28
- Compiled with Octane 3.04.4
- Fixed crash when using the "Copy as new materials" option on multi-selected materials

Paul

Hi Paul. Maybe it is a jnown issue, but I am still having problems with geocrafted props on G3F. The genital prop is not smoothley connected to the body in renders. It looks detached. Cannot post a picture here though

I am still having problems with geocrafted props on G3F. The genital prop is not smoothley connected to the body in renders. It looks detached.

Did you mean it looks offset from the body? Maybe it's a displacement issue; did you check if displacement is enabled on the genital material? If yes, try a mid level value of 0.5 or setting displacement to "none".

Hm, set the displacement value to zero in OCmat setting. It still looks detached.

It happens to me once in a while as well. Try reloading your scene, or reattaching. It works most of the time for me, but once in a the grafts just starts floating,