Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Found out the 'crashy way' that Render Queue and AM's LAMH Catalyzer do NOT work together. I still love RQ, but if it is even possible, it would be an awesome update to add support for LAMH Catalyzer scenes.
Catalyzer rendering requires using the render button in the Catalyzer pane. That is probably why it didn't work.
Yeah, I only mentioned it because *maybe* (hopeful fingers crossed) that could be an option added to Render Queue - where you could tick a box and have ONLY Catalyzer scenes queued up and let it do its magic! THAT would be Next Level Awesome!
I was about get the second update ready for release, but then I found out about this problem myself and I'd like to get a fix for that in as well. However, I'm still unsure why exactly strand-based hair doesn't seem to work and investigating, so please bear with me for a few more days. Sorry for the delays!
I'm sorry, I'm not presently aware of any method to pause a render. I'll have a look at the available programming interfaces once the other issues are resolved, but I can't promise that this is possible.
Ok, thanks for your quick answer and great plugin
I start RG and the first item in the queue almost never activates the denoiser and other items don't either seemingly randomly.
I am sorry, I don't have LAMH Catalyzer and can't promise that I will add support to it to the Render Queue.
BETA VERSION FOR UPDATE 2 (version 1.2.0)
Ladies and gentlemen, I've been promising an update for a long time, but every time I thought I had it about ready some new bug crept in. Since releasing a plugin update is a bit involved on Daz's side (they have to create installers for the DLL), to avoid pushing a buggy update to Daz, I have decided to do a public beta first. So if you would like to help me out and test this version, your help is much appreciated:
Please check this link: https://mega.nz/#F!rj4AlC7a!qvLCXlIoMMERNvaqbfoveg
The folder contains only the DLL, which you should copy to your
\Program Files\DAZ 3D\DAZStudio4 Public Build\plugins
directory (or wherever your Daz Studio is installed). The directory should have an existing DLL file of the same name. Please make a copy of the old DLL before copying the new one over it. You will probably also need Windows administrator permissions to replace that DLL.The new DLL is also time-bombed and will stop working in two weeks from today to make sure I don't get bug reports for it two years from now. This is beta code. It hasn't gone through Daz testing. For all these reasons also, please make a copy of the old file (or do a reinstall via DIM to go back to the original version).
The DLL is for 64-bit Windows only.
Changes in the beta code:
Use camera label, not name, for appending to target image file name.
Add a “Keep this window on top” option to the queue progress window that can be switched off to make the window better behaved.
Rename “active camera” mode to “single view” mode since the camera might also be the perspective view.
Fix wrong camera dimensions in “all visible cameras” mode if the cameras had local dimensions enabled.
Fix a race condition that would cause the Render Queue to stall during the “Open scene” phase in some situations.
Fix the “Shut down computer” box resetting itself if multiple scenes are in the queue.
Add quite a bit of logging to the Daz Studio log in case of problems.
Add a “custom script” restart mode by which the user can enter any batch file code to stop and restart Daz Studio.
Mark inaccessible scene files in the queue as “inaccessible” instead of deleting the whole queue.
Support for JPG, BMP, TIF output formats in addition to PNG. (Just type in a different extension when selecting an output file name. The new extension should be remembered for the next time.)
Fix a cosmetic refresh problem when target file name changed in the render queue window.
Add a workaround for strand-based hair and dForce hair (introduced with Daz Studio 4.11) missing in renders by forcing tessellation before starting render. For this one I'm especially interested in your experiences. :-)
Thank you all for your patience and for testing!
You could buy it today for 60% off with the flash sale, if you are so inclined. (I'm not encouraging that, just pointing it out). But Catalyzer is another plugin. Can one plugin invoke something in another plugin?
I am running Render Queue version 1.1.0 and Strand-Based Hair renders OK for me with Render Queue. I do have PR Tessellation turned on in my saved scene file. I think that is probably why it works fine for me. I have not tried dForce Hair with the Render Queue yet. I haven't tried your beta version yet.
Not to be pushy or anything, but if you would even merely CONSIDER adding support for LAMH Catalyzer I would happily buy it for you to test and develop! Say the word and I will drop a Gift Card on you to cover the cost so fast you'll wonder if you didn't already have it all along. <LOL>
I used the coupons for something else. :-) A plugin can call another plugin if there‘s a documented interface, but LAMH would be the first daz plugin I see to have something like that.
There are a lot a variables with the strand based hair unfortunately... I did find that the render queue did NOT generate hair with several scenes when the standard iray render did and thought I should try to make it behave more like it, which is what this beta is doing.
Thank you for the offer, but as barbult pointed out, there needs to be an interface too, and even then there would a lot of work to be done for LAMH support in the render queue. And given that Daz Studio now has its own hair solution I‘m also not sure I‘ll get any return on my investment of time there, which I have to admit is a concern of mine here...
I am using the 1.2.0 (built 2019-07-23) beta dll now.
In my first test scene, I turned off "Preview PR Hairs" on the Strand-Based hair and set the Viewport and Render Tessellation to the default values on dForce hair. With the Render Queue, the Strand-Based hair rendered, but the dForce hair did not render. If I render normally without the queue, both Strand-Based and dForce render correctly, so it looks like the beta fix for dForce hair is not working for this scene.
I was not able to uncheck the "Keep this window on top always" checkbox. When is it editable? The Render Queue Version 1.2.0 window is not the active window, even though the checkbox is checked (by default).
Saving as jpg worked. But what do you mean by "the new extension should be remembered for the next time"?" The next time I opened MF Render Queue and added a new scene, it defaulted to png again and did not remember that had previously changed to jpg.
I am rendering a scene with two cameras. One has local dimensions and a relabeled camera name. It rendered both images with the correct size and correctly appended camera label.
Question: Is it really necessary to close and restart Daz Studio between the multiple camera renders for the same scene? It seems a big waste of time to close and then reload all the assets again. It would be nice if it didn't have to do that. Is there any option for not shutting down and restarting?
I am using 1.2.0 (built 2019-07-23) beta dll.
What is the right way to cancel the render queue and keep it from coming on again the next time I open Daz Studio? (When I just don't want to render any more previously queued scenes. I just want to STOP.) The button to "Cancel render queue, ask me again next time" didn't do that. (What does "ask me again next time" mean? It didn't ask me anything next time I opened Daz Stuido, the render queue just started processing again.)
After a render queue finishes all images and I open the MF Render Queue again, the previous queue is still listed. Is that right? Am I supposed to Clear all to start over?
It uses less memory as multiple renders in the same session can be heavy on system resources.
I didn't realize that was a problem with renders of the same scene, unless render windows were left open (not saved).
Generally it isn't a problem, but with some content sets getting larger and therefore bigger scenes, I've gotten into the habit of rendering in multiple sessions.
dForce hair renders OK for me in the Render Queue if I set Render Line Tessellation Sides to 2 and save the scene that way before rendering it in the queue. I am using esha's grass in Foreground Blends to test this. If I leave Render Line Tessellation Sides at the default loaded by the product, it renders fine with regular render, but does not render with MF Render Queue 1.2.0 (built 2019-07-23).
OK, I will test this!
Thank you, noted! I made a last minute change to parent the render queue progress window to the daz studio main window and that makes it impossible to use the window at all, since the standard Daz Studio render progress window blocks it. There's no perfect solution here, but I'll do my last change for the next version.
That should have worked. Will also test this again.
Good. :-)
No, there is no option yet. The reason for restarting every time is that the "Daz running out of memory" problem is mostly one of Iray, I think. It seems that Daz doesn't always release all VRAM (or at least it that was true in the past) so the Render Queue makes sure it does by restarting Daz Studio after every render, since that problem would unrelated to which scene is loaded.
I'm a little hesitant to add yet another option, I feel like there are too many already and the workflow is getting more confusing and harder to debug. The Render Queue is really designed to run unattended, so I would prioritize reliability over saving a minute of time by not restarting in certain situations.
But thank you for testing!
Probably a wise choice to not add too many options.
Uh Oh! This same scene did NOT render the dForce hair in DS 4.12.0.33, even though the Render Line Tessellation Sides was still set to 2. Maybe it is intermittent, or maybe there was a change between 4.11 and 4.12.
I am using Render Queue 1.2.0 (built 2019-07-23) beta dll in DS 4.11.0.383
Problems/Unexpected Results:
Is it possible to request a way to have a setting to always render all active cameras instead of it having the default of single camera? Or allow me to select multiple scenes and have them all set to active cameras instead of one at a time? That's the only other thing I feel is missing!
I am really appreciating the Render Queue! Makes life so much easier, and has even saved my work from the dreaded Windows Update monster.
I have noticed two issues that I was wondering if I was simply misusing the Queue or no.
1) The RQ doesn't seem to respect the "Use Local Dimensions" data on a camera. It always renders whatever settings are in the Render Settings panel. How do I get it to properly render the camera? Right now any time I have multiple cameras in the scene I either have to render by hand, or make a temp scene for each one to add to the RQ, both of which seem wrong.
2) I frequently find an error message stating that Daz has crashed, sometimes multiple ones, after running the RQ for a while. It seems to correspond with the render window from renders earlier in the queue still being open (at least, when I click OK on the error message, those windows disappear). The render is properly saved. However, I have noticed that when a few of those are around, the current render frequently becomes very very slow, or even switches to CPU instead of GPU, so I think those errors are hanging on to memory.
hey ManFriday, I was very excited to see the addition of this feature, thanks for adding it!
Unfortunately it is still not working on remotely connected render PCs.
Why is there still the need to re-create the batch file each time if you could just point to an existing file instead?
This is the batch code I use to start DAZ on my render PC that is only connected via Remote Desktop Connection
When I add that to the RenderQueue custom script it asks me for the user credentials each time because the file gets re-created for each restart...
The attached image is just a reminder why I can't just use the included restart script on a remotely connected PC....
If the restart would be optional, that would be a nice addition too.
Same for the "_camera#" addition to the file name, which is nice for multi cam renders but really annoying to be removed from single cam renders.
Keep up the good work!
ManFriday, you may know this already, but Beta seems to open the files on Frame 0 / Perspective View in all cases.
Maybe that is just Beta behavior, but I think it would make Render Queue unusable.
I'm using the Beta dll of the Render Queue in the DS 4.12.0.42 Beta. It is rendering the single camera correctly and also multiple cameras correctly.