Chinatown crashes when rendering with Iray
CoyoteVisions
Posts: 13
Picked up the Chinatown product today (awesome as is pretty much everything Stonemason creates), but I can only get the 3DL version to work. If I load the Iray optimized version and start a render (using all default settings), the DAZ3D application crashes. Anyone else encountering this? Any suggestions?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
OS, system specifications, GPU, driver version? DS version?
Windows 8 64-bit, 4GB, Intel HD Graphics 4000, OpenGL 4.0 (Intel)
DAZ Version 4.8.0.59 Pro Edition (64-bit)
The error is DAZStudio.exe caused ACCESS_VIOLATION at 0033:0000000040EF3E80.
I checked the log file. No errors up to the point that I see the following, then no further information in the file:
Compiled C:/Users/russb_000/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/brickyard/{094bfaa6-1bfe-4b30-ab89-e0f423e6d404}/shader_Surface.sdl..
As indicated, 3DL version of set renders no problem.I can also load 3DL version of set, add HDR and few mesh lights, and render in Iray with no issue. Fear I have hit the point that maybe upgrading is not a choice, however, this is the first time I have run into this, whether using 3DL, Iray, Reality 4, etc. since first installing it last year so hoping it is something else (meaning money will have to shift from content to system upgrades.)
Russ
You do realize, that with your onboard graphics and Windows (I hope you don't have all the Win8 eye candy turned on) that you have way less than 4 GB available for rendering.
Yes... I keep it optimized religiously, usually get better performance than one would expect, and run with minimal features, but guess it is time to upgrade... promised myself I would if it got to the point rendering required too much patience or I ran into errors. A bummer since artistic needs don't always agree with financial priorities.
Russ
Is this a laptop?
If not, it shouldn't be too hard to up the memory...or costly.
It is a laptop. Originally acquired for digital painting so specs worked just fine for the need... then I found DAZ3D, caught the 3D bug, suspect you understand.
I have the exact same problem.
Operating System
Windows 8.1 Pro 64-bit
CPU
Intel Core i7 4930K @ 3.40GHz 24 °C
Ivy Bridge-E 22nm Technology
RAM
32.0GB DDR3 @ 799MHz (9-9-9-24)
Motherboard
ASUSTeK COMPUTER INC. X79-DELUXE (LGA2011) 31 °C
Graphics
ASUS PB287Q (1920x1080@60Hz)
W2453 (1920x1080@59Hz)
4095MB NVIDIA GeForce GTX 770 (PNY) 42 °C
4095MB NVIDIA GeForce GTX 770 (PNY) 31 °C
ForceWare version: 355.60
SLI Enabled
Disable SLI.
Did, no effect.
Also tried CPU only and all other combinations related to the render.
Also, that does not explain why this scene has the problem but 1000s of others I have do not.
There is something specific to this scene that is causing the problem.
This is known to happen. I've had it occur to me a few times. Once I re-created the scene from scratch, and that fixed it. Another time I re-created the scene, but it happened again. Probably a geometry or shader that Iray doesn't like.
From nVidia's docs, enabling SLI doesn't so much cause things to blow apart, rather is causes a bad slowdown because of a unique way the CUDA worker threads do their cooperative multitasking under Iray.
When you say, "I have the exact same problem," do you mean some arbitray scene is crashing your system, or the same Chinatown scene noted in the OPs post?
Also wanted to note the following whitepaper nVidia published. Note the part about deadlocking and timeout periods. The document doesn't mention how to extend the timeout (default: 2 seconds) in Windows 8 or 10, but I assume both OS's have some similar mechanism, should this be the problem. For me, on Windows 7, the system as a whole doesn't crash, but the Iray driver does, and take down whatever application was currently using the display. It's happened with Photoshop and D|S, and a few times with Poser, so not always related to Iray.
http://irayrender.com/fileadmin/filemount/editor/PDF/iray_Performance_Tips_100511.pdf
Yes, the exact same scene with the same error text.
shader_surface.sdl is some kind of generated file for the render, and I'm wondering if there's a materials/shader problem with something in the scene. Sounds like it would be hard to track down given the size of the scene.
Anyway, errors in this file crops up on renders other than Iray, too. If you do a Google search and then click the link to only show results from the forums, you can find some advice on ways to solve it.
I don't have this set, but it's from Stonemason, who's done, oh, one or two of these sets in the past. He frequents the forums and maybe will see this and can comment. You can also try PMing him: http://www.daz3d.com/forums/profile/Stonemason
I already reached out to him but have not heard a response as yet.
I'll download the store version today and have a look, I've had a few crashes with Iray but none using the Chinatown set, so not sure what I can do if it doesn't crash for me :\..you guys might want to go for a refund?
just tested again with the store version and it's working fine here,so there's not much I can offer to those having crashes other than a refund :(
my system is an i7,32gb ram,with a k5000 card and I can render the Chinatown set wth a couple clothed fgures included
Thanks for the offer but, No refund :)
I will take the 3D Delight version and convert the surfaces/shaders one by one on the 3 day weekend.
I think one of the shaders might be missing.
are you getting a missing shader message from DS?
The error is DAZStudio.exe caused ACCESS_VIOLATION at 0033:0000000040EF3E80.
CoyoteArt got the error below. Mine is essentially the same except the path is different.
I checked the log file. No errors up to the point that I see the following, then no further information in the file:
Compiled C:/Users/russb_000/AppData/Roaming/DAZ 3D/Studio4/temp/shaders/brickyard/{094bfaa6-1bfe-4b30-ab89-e0f423e6d404}/shader_Surface.sdl..
hmm,sorry I've got no idea what that could mean,,make sure you have the latest DS shaders though as I do use some of the iray specific shaders that came with DS
I have no problems with the rendersin Iray of Stonemason , first delete all lights !!!s create a new camera ! set the headlamp off, place a overhead led lamp ( Total Iray Rendering ) and wait ...
Rendersettings Normal Cpu M.treshold 1500x H.treshold 1500x test ...see picture
Remember delete first the 3Delight lights ...!
Are you talking about Chinatown? I have everything Stonemason has sold and the only one that has a problem is Chinatown.
Also, there is a special version of Chinatown for Iray and that is the one with the problem.
Thanks?
This error tells me that you are rendering with Iray, but that error comes from a 3Delight camera o light:
Over one week test the China town file...Aeternali we shall see...
In 4.8.0.59 it should not matter about the lights. There are only lights and cameras now, the proper settings will be sent to the renderer when it is chosen...
But for troubleshooting purposes, yeah, good advice.
ACCESS_VIOLATION errors are a pain to track down, because they can be caused by many things...from low memory amounts where what was expected to be in a certain memory location is actually not there, but was off loaded to the swap file to actual physical RAM problems to permissions problems (being read only when read/write is expected) and dozens of other things. Driver problems are also another source that has a couple of dozen ways of doing it, all on its own.
And all of that leaves out one of the big ones...DEP (Data Execution Prevention)...which is DESIGNED to throw an ACCESS_VIOLATION if something is trying to be executed from a memory location that is marked as a data location. And yes, shader files ARE executable files! Basically, DEP thinks it's a virus and kills the process.
Surely shader files are more like scripts - they are data that is interpreted by the application.
A compiled shader is/should be flagged as an executable file. A sdl file is closer to a dll than a script. That's what the main difference between a true shader and preset is...the shader IS additional code for additional functions that are executed at render time.
And, if for some reason, it's not, then it could very well trigger a DEP event.
Yep, but as OP is rendering in Iray, no 3Delight shader should be compiled after all, so we have to rule out the usual suspects. I think now it is more important to identify the root cause, not the effect we're seeing as an ACCESS_VIOLATION.
Correct that the OP is rendering Iray, but the sdl shader that is causing the violation may still be generated from any 3DL assets still left in the scene.
Or, there's a remnant sdl file from a previous 3DL render that's causing the shutdown. Sounds weird, but there seems to be a connection between using the 3DL version and the Iray version of the scene assets. Which application compiles the sdl file -- D|S, or 3DL?
I still think it's a good idea to remove any 3DL content, and not relying on A) D|S auto-modifying 3DL content to their Iray counterparts and B) relying on Iray's JIT substitution of material definitions.