Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Umm, please don't refer to them as "MDL iray textures". They are just plain textures, and in no way especially MDL or Iray related.
You could do me a favor if you check those textures which doesn't cause Studio to crash. Are they 32 bit?
I was just finally able to get a successful render of the "Material Ball" scene (which refused to get rendered on my system in the Public Build ever since) by stripping off all the textures. No crash, no "libneuray.dll" error message. When adding back the "Ball_NoLogo.jpg", Studio crashes, but adding the "Checkers.png" does no harm, and Studio did (to my again surprise) finally render through as well.
Checking those textures I found out that the "Ball_NoLogo.jpg" is a 24 bit texture, and the "Checkers.png" is a 32 bit one. "Spectrum.png" is also a 24 bit texture, and will also crash Studio when reapplied, "NVIDIALogo.png" is a 32 bit one, and it also doesn't cause Studio to crash.
Using the graphics tool XnView to convert the "Spectrum.png" from 24 bit to 32 bit prevents Studio from crashing, as well as converting the "Ball_NoLogo.jpg" to a 32 bit PNG. Rendering half a dozen renders with all textures converted to 32 bit: no crash, no "libneuray.dll" error message. Looks to me like DAZ's Iray 2016.2 plugin has a serious problem with 24 bit JPEGs and PNGs, but doesn't refuse to work with 32 bit PNGs.
has somone already the developers informed?
i want to make a bug report but "http://www.daz3d.com/redirects/bugs.php"; = not reachable
I will check, as far as calling them that....i am just going by how they are labled in the pane...so dont get so upset when someone who isnt tech savy doesnt realize that because i can only go by what i am presented with.
They are aware of it. For future reference the link is
http://www.daz3d.com/help/help-contact-us
ok thank you
Hi,
I'm aslo experimenting some issues with the newest version of the 4.9 Beta Public Release.
My GPUs are 2XGTX980ti. Windows 64bit.
At first 4.9 didn't render at all. The rendering window opened for a few seconds only and disapeared nothing happening. The interactive rendering window didn't worked either. I updated the graphic driver to the newest version for my GPUs from NVIDIA and it solved some issues. The interactive window seems to work but the rendering takes tons of time. I got this Verbose textos at the start of the rendering log:
Rendering in NVIDIA Iray
Compiling Shaders - 0/1
Rendering image
Rendering...
Iray VERBOSE - module:category(IRAY:RENDER): 1.12 IRAY rend progr: CUDA device 0 (GeForce GTX 980 Ti): Processing scene...
Iray VERBOSE - module:category(IRAY:RENDER): 1.5 IRAY rend progr: CUDA device 1 (GeForce GTX 980 Ti): Processing scene...
Iray VERBOSE - module:category(IRAY:RENDER): 1.8 IRAY rend stat : Geometry memory consumption: 11.7191 MiB (device 1), 0 B (host)
Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Geometry memory consumption: 11.7191 MiB (device 0), 0 B (host)
Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Texture memory consumption: 2.18128 GiB (device 0)
Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Lights memory consumption: 642.395 KiB (device 0)
Iray VERBOSE - module:category(IRAY:RENDER): 1.8 IRAY rend stat : Texture memory consumption: 2.18128 GiB (device 1)
Iray VERBOSE - module:category(IRAY:RENDER): 1.8 IRAY rend stat : Lights memory consumption: 642.395 KiB (device 1)
Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Material measurement memory consumption: 0 B (GPU)
Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : PTX code (73.1 KiB) for sm52 generated in 0.0562s
Iray VERBOSE - module:category(IRAY:RENDER): 1.13 IRAY rend stat : Materials memory consumption: 187.367 KiB (GPU)
Iray VERBOSE - module:category(IRAY:RENDER): 1.8 IRAY rend stat : PTX code (73.1 KiB) for sm52 generated in 1.4e-006s
Iray Iteration: 1
Does anyone understand what is happening and how I can solve it? I had a read on this post but I'm not very tech savy and didn't understand much.
I appreciate any help I can have.
Cheers
Yes I did, it worked, slow but it worked. It was not a complex scene or lighting but it worked. I have not tried GPU only. I will give that a try and let you know if it fails.
@ Arnold C,
I was mistaken, the shaders that didnt crash were actually just shaders..no textures. But going off what you said i found a few textures in my library that were 32bit and they work fine...but anything that is 24 bit crashes daz. I think you found the culprit but question is what is wrong lol
The method usually used to get the convergence values, for the progress bar, isn't working in the Iray 2016.2 SDK (it should eb fixed, Daz has been told, in 2016.3) so the renderer is running with "verbose" messaging, which from DS then extracts the convergence value for the progress bar. The price is more ... verbose messages in the history and in the log, but without it we would have no indication of how far along the render thought it was.
But how can we fix it so that it doesn't take an eternity to render? Now it takes a lot of seconds PER itiration. Before, with DS 4.8, and the older driver, it rendered normally with TENS of itirations per second.
Iray Preview Render / Regular Render crashes on AMD Phenom II and other AMD CPUs released prior to 2011:
It appears your latest build had some changes related to compiler optimisations that are causing crashes for IRAY renders for users with AMD CPUs that were released prior to 2011. The issue is a crash in neuray.dll with the ILLEGAL_INSTRUCTION code. I had guessed it might be an SSE4.1 instruction at fault since I had seen this issue with other applications in the past, but it turns out it was the SSSE3 instruction "pshufb" that is attempting to execute on at least some AMD CPUs (in my case, a Phenom II X6 which predates SSSE3 support on AMD). I'm guessing compiler flags changed somewhere (though this appears to be in the Iray renderer so it may not even be your code)? Or you're not detecting CPU correctly and going through an optimised path that contains code that our processors throw up on rather than a "more compatible" option.
There's more discussion here: http://www.daz3d.com/forums/discussion/89996/gtx-1080-iray-support/p19
Thought I'd pass that along - I've been able to get good renders on very simple scenes (or empty scenes) with my 1070, but once a somewhat complicated model is imported, it crashes just prior to the beginning of displaying the first bit of rendered content.
I'm not seeing this - in the past, and now, the first few iterations seem slow and then it usually (depending on content) starts doing multiples - and that's with a lowly 750TI. However, if you are seeing slower renders that would sound like a bug to be reported. It isn't connected, I would think, to the Verbose mode - generating a text string is pretty quick.
Information about how to submit a bug report (with links to the forms, but start here since it gives you the information you'll need to submit a bug report that the developers might have a chance of troubleshooting) is available here https://helpdaz.zendesk.com/hc/en-us/articles/207532333?input_string=bug%3A+4.9.3.117+-+crash+due+to+use+of+supplemental+streaming+simd+extensions+3+instruction+on+amd
I just submitted one for the issue I mentioned a few posts ago about the ILLEGAL_INSTRUCTION SSSE3 instruction I'm encountering on an AMD Barcelona generation processor.
+1
Why does my content library return so many unrelated search results in the newest beta? In 4.8 I would just type "victoria 4 cr2" for example and it would pop right up. In 4.9 it returns 1,200 results of unrelated files. I imported my old database from 4.8 and the mapped directories are the same as they were in 4.8. So I'm confused why I can't search for a simple file without getting all these unrelated results.
There has been a similar discussion in a differen thread and I hadn't noticed it had blown up over here, too. Assuming everyone who is crashing is receiving the "ILLEGAL_INSTRUCTION" issue in neuray.dll, one needn't reverse engineer the code to discover what the problem is, the problem is all actually reported there in the crash trace that is provided to help you give the Daz folks some information for them to troubleshoot. Unfortunately, *reading* a crash trace properly can be a little tricky. When I saw it first, I thought "SSE 4.1", because having a background in native development and owning an AMD processor, I've screwed up the compiler flags enough times to build a library that won't execute on my own hardware. SSE 4.1, though, as has been pointed out by a few folks in this forum, is not at fault. The ILLEGAL_INSTRUCTION exception is usually provided as a hex code (thanks, Daz, for not doing that!), and it's an indicator that the processor (CPU, not GPU -- more on that in a minute) has received an instruction that it doesn't have the ability to execute -- a critical fault that you can basically do nothing about. The rest of the crash trace points to a variety of information - the library, memory bits, (I think) entry points, and such.
I didn't do the later analysis, however, reviewing the trace, you can actually pull out the specific instruction (that is -- assembler instruction -- not anything that really reveals anything about the code itself) and you'll discover that the faulting instruction (at least for myself and one other user) was "pshufb". This instruction is *only* available on processors that support SSSE3 (that's "3" S's - Supplimental SSE3) and this set of instructions is only available on the latest 3 generations of AMD processors (it is also missing from some Intel processors, but far fewer). Now, many have pointed out "But I'm only using GPU rendering and it's *still* crashing!". Yup, that's right. The CPU is involved in some way *no matter what*. Or "but it only fails on complex models, not simple ones". Yup. The branch containing the fault may only be hit if certain conditions exist. In a little bit of research I did, this instruction shuffles bits according to a mask. It's commonly used in deinterlacing routines (in most cases hand-optimised assembly). It could be compiler flags, it could be a failure of CPUID to identify the missing SSSE3 support and "picking wrong" for this processor, it could even be hand-optimised inline assembler popped in by the devs to speed up some small, frequently called method that the compiler fails to generate optimal code for (I lean toward the latter case since compilier flag problems often result in larger scale failures and code for things like rendering, enc/decoding and such is usually riddled with hand-optimised routines because you often have a lot of code that's reused/executed over and over again and a couple of ms/ns shaved off of a routine that's called a billion times adds up). Based on just the name of the library, it's also probably not even Daz's code, but something in the Iray library provided by a third-party.
Frankly, all of the research done to figure this out, for me, has saved me some time. I'm no longer bothering to try to workaround the problem. It's simply not going to work on my hardware until the issue is resolved. If you want to confirm that you are experiencing the same problem, grab CPU-Z, run it and take a look at "Instructions". If you see "SSSE3" there (again, not SSE3), you won't run into this specific problem. If you do, you will.
To the several folks who are shocked, just *shocked* that something like this would slip past QA, all I can really say is you're not truly understanding the complexity of this kind of a beast. Native code is *hard*. Take a look at all of those little TLAs that appear in your "Instructions" part of CPU-Z. Those amount to a number of instructions that *your* processor supports. My list is different (maybe it has more, maybe it has less). The permutations of these are exponential. I have written perfectly valid C++ code with correct compiler parameters and *still* had things blow up related to the *compiler* doing something wrong (and if you can't rely ont he compiler to get these things right, you have little to no hope, yourself). Then stack on the fact that the compiler, which in the case of native code generally produces brilliantly fast, very optimised instructions, is *still* not good enough to get *every* optimisation right so now you have to take apart a few routines that are called a billion times during the execution of a render and do the compiler's job for it by hand coding some assembler. I promise you, you're going to miss a platform, especially one that you don't have many (or any) PCs around to test with. Or maybe you saw that pshufb was the *precise instruction* you needed and, *awesome*, it's suported by SSE3 (because, you know, that third "S" was probably written by a programmer who stayed up too late and was a little shaky, or maybe you just missed it the first time your eyes ran over the obscure reference you found to x86_64 assembly because *you're* the programmer staying up too late obsessing over a routine that's taking a couple of nanoseconds too long to execute) and you know that *any* processor that's missing SSE3 *probably* falls outside of the minimum requirements you've set for the app, anyway, so it's *safe*. And, holy crap, it's *fast*. Except when it crashes on a small subset of your customers running hardware you don't have to test with (or maybe you do but your tests don't load the right kind of model to exercise that particular branch). And on and on and on ...
Personally speaking, "all of the guessing" that took place in this post and the other post would have been endlessly helpful to me as a developer. There's *nothing* I like more than when my crash trace actually *provides* enough information for a customer to figure out what went wrong and that customer is able to give me a succint bug report pointing me at what I need to fix (well, short of not having a bug in the first place, but we don't live in fantasy land). Assuming we're all seeing *exactly the same thing* (which, I doubt), I would know where to look and what to do to fix it (with varying degrees of effort involved based on what the nature of the underlying code *is*, which is something only the guy/gal with the source code can identify). Now, I doubt there's just one bug -- even in relation to the crashing that is being talked about in the last few pages here -- but there's at least one bug that has been well identified with bug reports submitted to Daz.
For those of us getting the specific ILLEGAL_INSTRUCTION in neuray.dll, we can all relax. There's almost certainly nothing we can do until the next release and it's in Daz's hands to fix. It's also going to affect enough of a cross-section of their customers that it's not really something they can avoid fixing, so I'd be surprised if it isn't resolved in the next public beta. It sucks to have to wait, especially for folks like me who's only NVidia card and only hardware is among the affected, especially after being able to use Iray GPU accelerated for the first time (albiet on very simple models) and realizing how much faster it is. But such is the nature of wildly complex applications like these (and at the amazingly low price of "give us your e-mail address and maybe buy some models from our store", meanwhile the competition -- which is far buggier with a disgusting UI is incalculably more expensive).
...OK that explains why I am not having crash issues with my first generation i7 then. Just hope The old adage of programming "fix something here, break something there" doesn't come into play.
i am just glad that the current non beta 4.9 Public build still works for me or i would have nothing to do but stare blankly at my computer screen for hours on end wish i could make something lol
Daniel
Your diligence is appreciated, trust me, I am a developer and information from someone who has done such is rare and valued. However, guessing about problems in a closed/restricted forum where the participants are all knowledgeable and won't jump to bad conclusions and go screaming that "the world is ending" is far different from speculating in an open forum where the vast majority of the userbase is below novice level about the material being discussed. In cases like this, the signal returns to the developers are so overwhelmed with noise as to be less than useless. In fact, since this was such an anticipated (development/feature-set) far more folks who should not be loading beta software are, and the panic being caused by the unfounded suppositions is being amplified far beyond normal levels because "all they know" is that their systems are now "not working" even though they spent large sums of money on hardware that they were told would magically make their systems faster than greased lightning.
If the problem is indeed on DAZ's side and is actually caused by an opcode with limited scope, then it definitely falls on the "edge".
I have seen 2 valid/probable "guesses" so far in the open forums:
I have another theory, however (as mentioned) it is only a theory and I will not throw it out into an open forum. In my opinion, this is a multifaceted problem that has manifested itself in a manner that is very unfortunate for the circumstances. I am sure that once the Devs have a sure handle on the problem we'll be given information in due course. TBH, I am not altogether sure why they haven't pulled the release already.
Kendall
well why is there a discussion thread for the unwashed ignorant masses?
I know my mentioning the broken FBX export in a previous version was ignored totally and then it hit the general release and all hell broke loose with users of other software who buy DAZ content.
a lot more went down and those in the know know exactly what I mean.
Its stopped me discussing bugs thats for sure, I just stick to saving my general release installers so I can roll back when DAZ borks another thing up now.
At the top of this forum it states clearly:
Please note, bugs are reported by opening a Technical Support ticket http://www.daz3d.com/help/help-contact-us.
If you think you've found a bug, report it. The devs do not read these forums. Some PAs do on occasion, as I do looking for people having problems with my software, and may or may not pass along the information if they can replicate the bug, and have the time.
Kendall
oh I did submit a ticket at the time too.
Put the filename in quotes.
I feel like a dummy. Thanks! Now if I can just get the Show Asset In > Mapped Folder to work like it did in 4.8...
Apologies if my post sounded a little abrasive (absolutely not intended, but the nature of written word versus spoken word and human nature tends to make all interaction from people unknown -- especially on the internet -- carry the assumption of abrasiveness).
Generally, I don't worry about the inexperienced masses -- there's always that signal-to-noise ratio in any discussion on a public forum. I was really pleased to see such deep investigation from knowledgable folks (it saved me a lot of time figuring out what the format of the trace really was and I would have taken the time because I love a mystery ... especially one that I am equipped to solve). Plus, for me, anyway, reading public material from people experienced in the art helps me to become one of those people if that's something I'm interested in, so I generally just post away and ignore both the inexperienced responses and complaints about the weeds getting too tall, but that's me. It's all fun and games until someone links to the x86_64 assembler reference guide. :o)
Very interesting on the 24/32-bit component. At the risk of adding more speculation to the discussion, the two *could* be related. I've been trying to figure out what the reason is that simpler models seem to handle things just fine but more complex ones do not. It's clear because of this that the faulting code path is only executed in certain circumstances and that might be one of the circumstances. Unfortunately, it's been about a year since I've written inline assembler and I *avoid* anything related to that at all costs (it requires a few browsers opened up to various spec documents, a whole lot of reading and a way to little coding -- and I'm *not* good at it since I do it so rarely), so I'm not sure as to where this particular instruction would be useful (i.e. does a 32-bit value fit perfectly whereas a more appropriate instruction would apply, perhaps a 16-bit and a second instruction for a 24-bit value; no idea -- I'm inexperienced in this area). Identifying a set of circumstances that's "more specific" than just "a complex model" would be neat, but probably not worth my time to dig into since I'll wager this will get resolved in the next release of Iray and/or Daz (here's hoping, at least, since I was blown away that the manufacturer of my video card -- released in June -- had failed to provide software support for some of its major selling points until a few weeks ago).
I'm having a strange issue. After doing a sav scene subset, all my renders get stuck to viewport resolution, changing Dimension Preset does nothing. Anybody have this issue? i want to ask this here before I send a ticket.
Known bug, fixed in 4.9.3.123. Until a new public beta is released with the fix, if you load a scene with the dimensions you need, that will set them properly.
Thanks. Good to know.
Urgh.
Not having any problems with the Beta yet... because I can't install it!
Downloaded the two files to a USB drive, transferred them to my 3D computer - Install Manager Downloads folder.
Fired up DIM, it showed them as "ready to install".Clicked "Install".
Public Beta Content 1 installed as 55 bytes.
Scene Builder failed to install, Installed path for "DAZ Studio 4.x Public Build" is not defined.
Went to "settings-applications-add application" and there's no public build listed to add.
Can someone please help me get this on my computer? I have the latest version of 4.9 installed, although I mostly use 4.8 still. Thank you.
Petercat Could you install old version beta with your install way ? you need package "daz studio public build " your downloaded those two zip are jsut contents for the daz studio,beta,,
then it need actuall beta daz stuidio aprication.
I heared before,, we can only install public build beta, by DIM. but I do not know,, if daz already change, and offer beta , for User (who can not use DIM for each reason or not hope to ) too.
then I check now my product library,, I feel,, if you try "off line DAZ connect package,", you can install public build,,, (but I could not find manuall downalodable zip without daz connect thing)
But I believe, if you send ticket, with your reason , DAZ may send you zip package.
I saw topic about your management way for daz contents without Internet for 3d play pc, then was impressed.
your patience and effort . (I thought ,,you seems use DIM without internet, manually place zip to the downloaded directory,, then it usually offer meta-data too,, then you may use content library
with category,, could not you (sorry it is not your current problem) ,,, anyway,, send ticket and ask DAZ,, hope they offer you zip.