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.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
Thanks!
You wrote in another post that the base MDL directories in shader mixer are of more high priority than the default ones in program files\Daz3d\... . I understand it in a way that if there is a core_definitions.mdl in the user defined MDL directory (set in shader mixer) it will be used instead of the default core_definitions.mdl in program files\DAZ3d\ .... Right?
@cgidesign
I have not found this documented anywhere, but my testing shows that is how it works in 4.16.0.3 and nothing in the changelog leads me to believe it has changed in 4.16.1.31.
Thanks, I will check it with the beta.
...the last really beta I worked with which I xonsdered "rock" stable was 4.12.0.47. which is why I kept it working with it so long (particularly as the earlier versions of 4.15 were rather buggy). It was even more stable than the General 4.14 release
The only time I had it crash was when I was working on an extremely heavy a scene that exceeded system memory.
I since backed up to a relatively stable beta version of 4.11 as the updated version of Iray in 4.12 was optimised for the new RTX cards (20x series) and I have an older GPU. Nvidia did a "fix" so that older cards functioned more like the RTX series but it was at the cost of VRAM. This means having to make a decision to dump the 4.11 beta for the 4.16 one which means effectively tuning my Titan-X into a 1070Ti VRAM wise.
Be sure to check the new GPU driver requirements.
https://www.daz3d.com/forums/discussion/529616/daz-studio-pro-4-16-1-was-4-15-1-nvidia-iray#latest
Exactly like me, stuck forever on 4.12. No fixes for animation tools in this release once again.
Undo stack is pure evil, registering perspective and ignoring slider changes.
...currently running 472.59.
Hello, I have a problem and I think it is not difficult for programmers to adjust this.
I render everything on a render server, and sometimes the hair appears flying above the character, or the clothing is a little off.
I found that this happens because the server starts rendering before the hair and clothing adjust to the body, or while they are still doing so, the autfit.
Analyzing the log, I believe that Daz considers a scene fully loaded when it finishes loading the geometries, and forgets about the autofit, which occurs after this process of loading the geometries.
Look at the log below:
On line 2 the daz gave a "Locking viewport"
On line 46 the daz releases "Viewport redraw unlocked"
But the morph projections only start after that like lines 47, 49 and 51
That is, Daz is still "adjusting the scene" but has already given the server a ready scene flag. This is an ugly BUG.
471.41 is still the minimum for GPU rendering.
...I always go a step or two above the minimum
I have installed 4.16.1.34 Public Beta. Some shaders that work fine in 4.16.0.3, render incorrectly in 4.16.1.34 Public Beta. For example, some of the custom shaders used in UltraScenery render all black. I have tried both NVIDIA 511.17 Studio Driver and NVIDIA 497.29 Game Ready driver. I have rebooted my computer between driver changes.The only MDL base path I have mapped in Shader Mixer is C:\ProgramData\NVIDIA Corporation\mdl.
@barbult
That MDL path is for the NVIDIA MDL Exchange. Have you tried removing it to see if it resolves the issue?
Alternatively, have you tried updating the MDL Exchange to the latest version? (The download link is near the bottom of the page)
Thank you. No, I haven't tried either thing. I really don't understand the whole MDL directory thing very well. I used to have 1.4 and 1.7 mapped and I deleted them. I did not realize the remaining directory was related to them. I'll delete that, too and try again.
@Omniflux I deleted that MDL exchange path and restarted DS beta. It looks like that solved a lot of my problems! I still see one shader in my scene that is wrong, so I'll do a little more investigation of that. Thank you for such valuable and quick help!
barbult said:
On my Win11 system I only just (today) started seeing 511 for the Studio driver, and my update (GEForce Experience) is to 511.09; like @kyoto%20kid I'm on 472.12. Despite this I don't see any problems, though I haven't been doing much rendering lately. I notice NVidia say that 511.09 was available on January 4, but I certainly didn't see it then (and I have done a complete reboot many times since). I guess I'l try to download it, but it seems quite likely that this is all an NVidia problem - I suspect they don't care much about the Studio driver because the people who use it are in production environments and don't upgrade anything until they are absolutely forced to.
"Error preparing objects to simulate" everywhere :)
Is this something known? On nearly everything?
Nv driver is the latest.
At the end of the log (immediately after collision offsets):
2022-01-26 11:13:34.452 [INFO] :: Shortest spring had length: 0.0221572
2022-01-26 11:13:35.850 [WARNING] :: ..\..\..\src\dzdynamicsengine.cpp(3293): ERROR: clFinish (-36)
2022-01-26 11:13:36.049 [INFO] :: Total Simulation Time: 4.71 seconds
2022-01-26 11:14:16.141 [WARNING] :: ..\..\..\src\dzdynamicsengine.cpp(2489): ERROR: clEnqueueMapBuffer (-36)
2022-01-26 11:14:16.148 [INFO] :: Total Simulation Time: 0.82 seconds
No problem with Studio 472.12 in either 4.16.1.30 or 4.16.1.34.
No problem with Studio 511.09 (the latest driver, as of a few seconds ago) with 4.16.1.34
No error messages like that with 4.16.1.34 (either driver.)
The simulation time with the latest driver seemed similar to that with 472.12. I don't notice any black hair issues either.
I switched to studio drivers (with a clean install) but still same error.
dzdynamicsengine.cpp(3293): ERROR: clFinish (-36)
dzdynamicsengine.cpp(2489): ERROR: clEnqueueMapBuffer (-36)
Something got broken along with the 500 series for me. I have two video cards (a titan v and a 3090) and there hasn't been a single glitch before 500 series.
I have tons of crashes when I am in the shader mixer, furhtermore some brick networks, even simple, don't have the same result in comparision with the "normal" build (same scene with same shader mixer network, drastically different results on metallicity behavior). Does anyone has the same problem, playing in the shader mixer? It particurarly happens when I work with metallicity and modified base colors (multiplied by other mapped values for instance).
Sounds like it is time for a request ticket... I'm using a TitanXP. You could try using the CPU for the simulation, though in my experience it has to be a really simple case.
That is quite a vague description. Definitive and detailed examples are better to investigate.
You're right, it was late and I was angry (both prevent my brain from working properly). I join here the images. In the images you have 2 spheres mapped only in base color and metallicity (black and white stripes for metallicity, color rainbow for base color). The background sphere is always Iray Uber Base and nothing else, whereas the foreground sphere is always having the same shader mixer shader (scene is saved in 4.16.0.3 and reloaded in 4.16.1.34, but this is the same if I reapply the shader mixer shader directly in 4.16.1.34). You see that the metallic parts become (and always become, I tested on other base shaders) mirror grey.
So I had a deeper look in the shader mixer (I reversed progressively the brick network to see when the problem appears), and the "metallic" behaviour fails (I mean as shown in the image) as soon as various operations (not all but a lot of them) are made on the base color between the base color map (coming from user parameters) and the base color input of the PBR metallicity base main brick of the shader. I (rapidly) tried to clamp the "tweaked" base color before it enters the PBR Metallicity base main brick, but the clamp brick refused to connect. So I decided to "normalise", the normalise prevents the problem to appear if I remember well (not 100% sure, then it was super late), but also makes it impossible to change the base color properly (since at the end, it is always normalized). So the metal look probleme clearly has a link with 'at which' level the base color enters the PBR Metallicity Base brick, or what happened to it before it enters... (but I found no way to clamp it, since the clamp brick really refuses to be connected)... Anyway, clamp or not, there is an obvious difference between 4.16.0.3 and 4.16.1.34.
The crashes of Daz Studio seem to be pretty random when I tweaked the shader in the shader mixer: sometimes it could be in the mixer, sometimes just after I applied the shader, sometimes when I changed a value in the surfaces editor.... But I never could replicate a specific crash, so I have no way to replicate anything. I made a video of a crash when only I changed the base color color from grey to white, I can share, but I'm not sure it's intresting because it cannot be replicated. A random crash...
(edited for a more clear english)
Do not make a French woman angry
Thank you for the explanation and examples.
You're welcome, feel free to contact me if you need more information !
Hi all,
is anyone experiencing the weird texture behavior I have in the beta? See the pictures of a vanilla Victoria 8.1 in a render and in NVidia preview.
It seems the different "texture areas" (if that's the correct term) get arbitrarily colored.
Tested w/ latest 4 and 5 studio drivers, same result. So with gen 8 models. Caches deleted.
Does not appear in 4.16.03 (GA).
Any idea what to do here?
Best wishes,
H.
I don't know if it can help you I also had weird issues of maps from other properties were so visible that one could think they were the base color maps. It looked a bit like what you show here even if it is not exactly the same. I had one or that two arms and the head surface rendered "with the top coat map" or fully white. Things got better when I used invert normal off on all surfaces (I think I also turned top coat off, but not sure). Not sure it will help, but turned normal off saved my work on that day.
Please see Acceptable Ways of Handling Nudity for guides on image posting
It certainly looks as if the wrong maps are being used - a lot of them are maps from a different UDIM tile, though it does also look as if a (wrong) normal map is being used for the base colour in at least one of the images. I have seen others reporting similar issues, though it doesn't seem to be universal and has happened occasionally in the past
Not sure what I was thinking when I decided to bring an important project into Beta but running out of time on an image I'm making for a charity event. But I did, so, here I am.
If I try to bring it back from beta into 4.12 version it crashes. I’m not sure what it is it didn’t like from the beta version it doesn’t like but it clearly doesn’t like something.
The reason I can’t do what I need to do in beta is I’m using a chimp from AM. It seems the only way fur is visible is with the Catalyzer version. Beta, at least for me, will crash when I try to bring in a Catalyzer version into the scene. I can make a scene with him alone in beta, but a no-go into the actual scene I need him in. I’ve tried saving him as a scene subset but beta crashes if I try to merge him in.
SO, any suggestions on how I might do one or the either. Get a beta to open in 4.12 OR get Catalyzer to work in Beta? Would actually prefer the former than the later as I’ve yet to set up my toolbar and certain preferences in beta but any solution will be most welcome.
...that's sort of me in a way. Still on W7 here until save up enough to make the upgrade needed for W11 (right now a little over 800$ - and that doesn't include the cost of W11 Pro [Retail version] which makes the grand total just over 1,000$).
Currently sticking with 4.15.0.30. I read the procedure for installing the downloaded MDL files above, sort of maybe understand it, but just don't want to mess things up.
Great thing about this Beta, my Genesis characters load much, much faster, I mean a full 4-5 minutes faster, the bad news is that Daz broke some scripts for my favorite plugins, specifically Zev0's X-Transfer!