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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
So instead of fixing my bugs with my purchased Product, I have now to pay again?.... sounds not fair to me.
I wanna use my product I did purchase and I can't understand why it disables always the Smoothing filter and why you can't fix it...
Thanks a bunch! It's a really great tool for any 3d-artist! I'm sure the wrinkles will get ironed out!
Very awesome, I saw it finally come to the store the other day and pulled the trigger yesterday! ! have been trying it out with about 40 renders over the last 24ish hours and so far so good, mostly. I have another batch of queued up right now along with a short animation to test it's ability to do the animations and will need to run them overnight, but I have used it a few times for static renders and it has worked well. I still need to test it to see how it will handle my animals and their fur issue that I reported previosuly. I have a few of those scenes on my list to render tonight, so we shall see.
As for my request for the ability to bulk move scenes on the list, it still does not seem to allow this. It will only move 1 scene at a time, even if I select multiple of them. It looks like you have it set to grey out the options to move a scene when multiple are selected. I have some knowledge of scripting so I will see if I can make it do this on my end (if possible), and if I figure it out, I will share my solution with you. But since it's your code, you are much more familier with it, so it may be way easier for you to figure out. Do you think this is something you can add/fix?
BTW, I "think" I may have found something that is a possible oversight, but I need to confirm it. I think the logic may be counting the icon and tip renders towards the number of items to render limit before restarting. I thought I saw it restart Daz too soon and it did this right after it rendered the image, but not the icon/tip, but I may have just not been paying attention fully. I will let you know if it is in fact doing this once I start my queue before bed.
Thanks again, loving the changes so far!
Depending on when you purcahsed it, Daz "may" be able to issue a store credit and remove it from your account to allow you to get the new version, but just like with most software these days, we usually have to pay latest "major version". Bug fixes and minor things are usually part of the version we buy, but when it comes to many major new features, it is super common for there to be a charge for the latest version. I personally do think owners of v2 should have received some sort of discount to get the new version, even if that discount was available for like 1 week, issued a store credit for a portion of the cost, or something like that, but nothing we can really do about that sadly.
Is there an ability to pause & resume renders?
The icon and tip are each separate renders. They are just small size image renders saved in the scene file location. So it makes sense to me that each would be counted in the number of renders before restart. If you are rendering tip and icon for each queue entry and don't want Daz to restart between them, maybe you need to multiply your number of renders before restart by 3. Or maybe ManFriday has a different idea about this situation.
Love the product :D
But I didn't come here only to sing praises. So Daz memory leaks... this may not surprise anyone, but it was to me. I have scenes that sometimes fail to render, and a restart of Daz usually fixes it right up. I've disabled CPU fallback - "you either render it the way I intended in the amount of time I've allotted, or you don't render at all" kind of thing. Anyway.
I've noticed that it doesn't appear to shut down Daz for the restart. It says it does, and then waits, but never does Daz actually shut down in a clean manner. It always ends up with the taskkill (see attached). Now possibly I need to give it even more time, although I would say 90 seconds to shut down any application on an I9 12900k should be enough.
Any tips on this?
This is the exact reason why Render queue used to restart Daz after each render. Its a problem with Daz and everything getting loaded into memory from the scene. If you load up multiple sceenes, it causes a big of a traffic jam of data in your memory. That is why it is best to restart Daz after a set number of scenes that have been rendered. I don't know all the technical reasons for what causes it, but I dummed it down to the basic idea as I understand it lol. I currently have mine set to 4 and do not have the icons/tips set to be generated and so far that seems to be working well. They stay pretty consistant so far. May need to do some testing to see where my limit is to need to restart.
Also, another thing i do to solve the Daz taking froever to close problem is to just have render queue Kill the daz process. You will not hurt anything by doing it and it is WAY faster then waiting for it to close properly, but I have noticed if you make any changes to the UI or anything like that and do not let daz close right, it may not restore those settings the next time it starts. Not really a big issue for me but something you may want to pay attention to.
What you say makes sense, but the idea or reason behind wanting to restart Daz after a set number of renders are done is to deal with the memory bloating issue it has when multiple scenes have been loaded in the same instance of Daz. Rendering a couple of extra small renders from the same scene really won't affect this so it should not be counting those towards the render count IMO. Yeah, I can account for them myself, but I feel the logic should be adjusted for this.
So as I feared, my scenes with the "Moshi the Kitten" model in it did not render the Fur right, so it looks like this is still a problem. I did see when it loaded the scene to start rendering, that it said it was starting the strand based hair thing, but clearly does not effect the fur here. Here is a comparison to what I am referring to so you can see what I mean. Left side is the one rendered by Render Queue, and right side is me doing it by hand. When I render them by hand, it works fine and I do not need to take any extra steps so there is clearly something missing from the process of loading up the scene or triggering the render from a script. Some setting is not being enabled that should be.
For some reasin, Render Queue 3 cannot render dForce hair Line Tessellation 1 correctly, so it forces it to Line Tessellation 2. What Line Tessellation does Moshi use? (Look in the Parameters pane for that info.)
So looking at the parameters, I assume it will be the "Render Line Tessellation Sides" option in this case since the only other one is for the viewport setting. Checking the Fur and it is fact set to 1. When I preview it in Iray preview (which was set to 2), it does in fact do the same thing that render queue does. The moment I change it to 1, the preview looks correct so you seem to be correct.
Now here is something interesting. I saved that scene with the "Viewport Line Tessellation Sides" to 1, added it to the queue, and then told Render Queue to run. (without restarting daz or reloading the scene, so before I run it, it was still set to 1). The moment I hit run, the script starts, and instantly changes "Viewport Line Tessellation Sides" to 2. Keep in mind that "Render Line Tessellation Sides" remains at 1 but my render still came out wrong, so clearly what ever command that is being used to trigger the render process, is somehow treating it like its being rendered from the viewport, so the "Viewport Line Tessellation Sides" setting get used. The moment I stop the render, it changes back to 1 right away, so it seems you are correct that it is somehow defaulting or forcing that setting to 2.
The strange thing is I checked the change log for RQ3 and I can see it is mentioned in here about this known problem, but they are saying it should be forcing the "Render Line Tessellation Sides" to 1, but that is not what I am seeing. Sadly it is not a typical script file that I can edit, but a DLL and I don't really have the tech kills to try and unpack or hex edit it to see if I can tweak this. I really think we should be given the choice to have this setting be forced or not. I suspect that in my case, everything will look fine if the script was not forcing that setting, but I cannot confirm this without changing how it works. Please allow us the choice to do this @ManFriday!
Anyway, so after figuring this out, I decied to try something. I set both setting to 1 and then locked them to see if Render Queue would be able to override them and sure enough, it was not able to and my render worked perfectly! Render Queue could not force those settings anymore and thus, the fur rendered how it was supposed to. I am not sure if ManFriday will see this, but I really hope they can do a little trial and error with this information and apply a fix. Thanks for pointing that out, at least I now have a solution to this problem!!
EDIT: Testing out verious settings to see if one, the other, or both need to be locked. Will update when I know more.
EDIT 2: Okay, after testing things, just setting "Viewport Line Tessellation Sides" to 1 and locking it is all that is required but I think there is 1 more step. While the fur is rendering in full now, it is slightly darker than it should be. Trying out some other things to see if I can solve the reason for this too.
I am getting error messages when trying to add any scene from my local library to the render queue:
2022-11-15 11:48:40.945 [INFO] :: RenderQueue: Critical error message box in ManFriday's Render Queue V3.0.16: Failed to add scene files to queue: failed to find component “” from path “\\Quasar\LocalHome\Documents\DAZ 3D\Studio\My Library\Scenes\highland_queen002.duf” on disk
I have mapped my local DAZ libary (Documents/DAZ 3d) to my network share via a symoblic link. Judging from the error message, ReenderQueue V3 does correctly parse the URI, but fails to open the file. Accessing the same file via DS works as expected. Mocing the file to a path on my internal disk and then adding it to RenderQueue also works.
Edit: If I navigate to the scene on the share using the file dialog, starting from the mounted root (\\Quasar\LocalHome), it works as well. The issue seems to be just with symbolic links to SMB network shares (which works in every other scenario I have used with DS so far)
While the Render Queue is running, you can just close the big progress window that has all the jobs with the close button. The Render Queue will remember its state, and you can press the "Render" button again to continue.
The Render Queue does some file component parsing for the automatic renaming, and it looks like it doesn't handle the double backslashes well. For me to be able to reproduce the scenario, what do you mean by "symbolic link"? I'm assuming you are not using the Render Queue under Linux, and creating symbolic links under Windows is not something that is supported easily out of the box. So can you clarify how to did that? Thank you!
Thank you for answering this, barbult, and you are exactly right. The Render Queue counts renders, not scenes, when it comes to restarting Daz Studio. The reason for this is that it is the rendering that can cause memory issues, not the scene loading.
Daz Studio can take a long time to really shut down. When you close its main window, it looks like Daz Studio may have exited, but the dazstudio.exe process keeps running in the background and cleans up things. Why that takes so long exactly is a mystery to me, but it does seem to be a function of what is loaded in the current scene. If scene loading takes long, then scene cleaning takes long, and that is what's happening when Daz Studio exits. And both take a lot more time depending on how many Genesis figures are in the scene and how many morphs you have installed for these.
A faster processor won't help much. Cleaning up your morphs may help. My Genesis 8 used to take minutes to load, and I have managed to get it back down to seconds by moving a lot of morphs (figures and morph packs) into a separate library that is normally disabled. It is a laborious effort though.
No, I am using RenderQueue under Windows 10, But as I have quite a large set of assets, plus I am using an iMac for perparation of scenes, I have moved all things that should be available on both setups to a network drive (Synology, via LAN). To make the directories available for DS, I have used the Windows mklink command. Instead of having a "real" Daz 3D directory in "Documents", there is a "DAZ 3D" folder created with mklink. That folder links to my network drive. If you access that "folder" from Windows Explorer, it looks as if you are accessing local files. The idea was to have a DS default setup (shared library in the shared user folder tree, privarte library in the local user folder tree) on both machines, without any changes in DS. It did work so far, also with the previous version of RenderQueue.
When I try to "add" a scene, the file dialog pops up as it should. If I point that dialog to the DAZ library via the symlink in "Documents", I run into the error. If I navigate to the file starting at the mount point (shown as a drive on the file select dialog), then navigating to the scene, it work.
Same applies if I use "add current". If the scene was loaded via the symlink, "add current" does not work. If I have loaded the scene via the full path, it works.
I'm sorry, I never replied to this. I still have this on my list, and I can see why it's annoying to have to move many scenes individually and by hand. My original plan was to allow for dragging and dropping scenes around but implementing drag and drop is a bit of a pain so I never got to it.
I haven't forgotten about it!
Editing a DLL is not really an option, it's full of machine code. :-) I will wait for your additional testing results and see what I can do about this. It does seem that Daz Studio does not want the Render Queue to use a tessellation setting of 1. I will also investigate with Daz what could be the problem here.
Please keep me posted about your findings. If locking the setting really helps, I can add that to the RQ too as well, or just leave the setting alone.
Thank you for the clarification. All the functions you mentioned use the same file name handling code and that doesn't seem to be handling the double backslashes correctly. I'll have a look.
Side note: I have checked again, and directly locating the file from the mount point will store a drive letter in the JASON file (Y:\Documents\DAZ 3D\Studio\My Library\Scenes
howver, the target path in the JASON shows to my render library, but with forward slashes //Quasar/LocalHome/Documents/DAZ 3D/Studio/Render Library It renders fine, though. Renders are store to the selcted location.
Thanks for moving the posts Richard Haseltine , I did not want to reply till you had.
Thanks for the info @ManFriday , I did a bit of trial and error last night, but have not been able to figure out why the fur was not 100% right just yet. It is certinaly much better than when the "Viewport Line Tessellation Sides" gets forced to 2, but it's not how it should be so I will let you know if I ever figure it out. What ever the problem is, it is shared between the Iray Prevew mode, and how ever you trigger the render process becuase in Iray Preview mode, it looks exactly the same as when I use Render Queue to trigger the render.
What ever process is used to start rendering when we press the "Render" button seem's to work differently or includes settings that neither the iray preview nor RQ use, so it has to be related to that in some way. I am honestly wondering if you are using the right command to trigger the render process. Maybe there is some other command that needs to be used and right now you are using the command that renders in "Iray Preview" mode instead of the normal render mode. It's just a thought as I do not know enough about it all to say for sure or not, but that is just how it feels to me, especially since "Viewport Line Tessellation Sides" is the setting that is affecting my renders when I use RQ, and not "Render Line Tessellation Sides" when using RQ to start the render.
I tried rendering 4K 30 animations.
When rendering with Render Queue 3 rather than rendering normally,
It takes about 30% more time.
Probably, it is thought that it is the cause that it becomes slow to be displayed on the screen every one.
Is there any solution?
Normal rendering: 7 minutes 39 seconds (459 seconds)
Render Queue 3: 10 minutes 06 seconds (606 seconds)
I just wanted to let you know that RQ3 does, in fact, ignore the missing Gen 8 essentials window. I was able to render 32 images without any hiccups. (Just straight-forward 2560x1440 HD .pngs.)
Thank you!
Hello,
is there a "use selected render setting" option ?
I had already asked the question on the first "render queue" that you had published and I take the liberty of asking again because it's an important option for me, thanks
That is saved in the scene being rendered.
I'm not sure I understand, I'm using a translator but if I understand correctly, I know that the settings are recorded with the scene but the ability to choose the render settings in "render queue" for example allows not to have to modify an animation of 300 frames one by one in case we decide to change the render settings
The doc is right, by default, the Render Queue uses the render settings that were saved with the scene. This is true for the old and the new Render Queue.
The new Render Queue 3 has a new feature though: you can ask the Render Queue to load render settings (or any other Daz Studio file) after it has loaded the scene, but before the scene is rendered. This is called "Pre-render asset loading" and is described on page 6 of the PDF manual. If you save a render settings preset and add it to scenes in the queue via the scene settings dialog (select scenes and press the "Edit" button), you can add such preset files for the selected scenes.