ManFriday's Render Queue (the old one from 2019) [Commercial]

191012141518

Comments

  • Keyless said:

    Anyone else having their renders come out pitch black when using Render Queue? 

    I've set up the lighting and it works fine when I Render it manually. Any suggestions?

    Update: It appears it has nothing to do with Render Queue after all. For some odd reason, my renders are coming out dark. But if you notice the bottom of the picture I uploaded, there's a bit of the picture that started rendering properly. Solution unknown but I changed a point light from a Sphere to a Rectangle in one scene, and it started rendering properly. 

    Update: It wasn't the Point Light. Still not sure why it's happening but I have fortunately been able to avoid the issue since. Wish I understood the problem as to better avoid it in the future. If anyone has encountered this issue and knows why it happens, please let me know. 

    This happens to me ALOT.  There has to be some common thread, but no matter the lighting or camera DoF settings (the only variables that have occurred to me to check), i have a very high chance of getting the exact same error.

  • c.loth1975@googlemail.com[email protected] Posts: 69
    edited November 2020

    Hello,

    I have a problem with the Render Queue and maybe someone can help me out? I'm using DS 4.14 and I tried to render four scenes queued in MF's RQ. After a scene is finished, the software tries to restart DS, but it seems to fail. DS doesn't restart, and the log stops with the following messages:

    2020-11-15 00:35:45.274 RenderQueue: Entering  restartDazStudioOrThrow(): restart mode is 1
    2020-11-15 00:35:45.280 RenderQueue:   calling dzApp->quit()
    2020-11-15 00:35:45.280 RenderQueue:   spawning stock restart script
    2020-11-15 00:35:45.280 RenderQueue:     creating restart batch file
    2020-11-15 00:35:45.281 RenderQueue:     batch file is “C:\Users\cloth\AppData\Local\Temp\mfrq-restart.bat”
    2020-11-15 00:35:45.311 RenderQueue:     ShellExecute() returned HINSTANCE 42
    2020-11-15 00:35:45.311 RenderQueue:     GetLastError() reported: 0
    2020-11-15 00:35:45.311 RenderQueue: Leaving  restartDazStudioOrThrow(): restart mode is 1
    2020-11-15 00:35:45.316 RenderQueue: Leaving timer event for 'restart daz'

    And there the process is stuck. Only when I quit everything manually, the log continues with a lot of messages. Then after manually restarting DAZ, RenderQueue continues.

    Was there a change in 4.14 that prevents a proper restart? Or is it something on my side?

    Best regards

     

    Post edited by [email protected] on
  • Same here, render queue restarts once, renders the second scene, and then it stops until I manually close and restart DS , and then it renders 2 scenes again before being stuck.

  • cloth1975 said:

    Hello,

    I have a problem with the Render Queue and maybe someone can help me out? I'm using DS 4.14 and I tried to render four scenes queued in MF's RQ. After a scene is finished, the software tries to restart DS, but it seems to fail. DS doesn't restart, and the log stops with the following messages:

    2020-11-15 00

    I have the same problem with 4.14 , except it manages to restart once, renders the second scene, and then it fails to restart for the following scenes.

  • ManFridayManFriday Posts: 549
    edited November 2020

    I am planning to submit a Render Queue update to Daz soon to fix all the restart problems once and for all. Those who have been having problems, could you try out if this version fixes it for you?

    Render Queue beta version 1.9.3

    Please check this link: https://mega.nz/folder/K7wQzLaA#MuqXZ9EwQLrTQoE39xK9pQ

    The folder contains only one DLL file with a fix, which you can copy to your \Program Files\DAZ 3D\DAZStudio4\plugins directory (or wherever your Daz Studio is installed). The directory should have an existing DLL file of the same name.

    Note that if you have multiple copies of Daz Studio installed (e.g. the public beta version), the DLL needs to be copied to each one of them.

    Important notes:

    1. Please make a copy of the old DLL before copying the new one over it.
    2. You will need Windows administrator permissions to replace the DLL because the plugins directory is protected. You cannot download the files directly into that directory, so please save the files to "Downloads" or some other place and then copy them using Windows Explorer.
    3. The new DLL is time-bombed and will stop working four weeks from today to make sure I don't get bug reports for it two years from now. The Tool Settings dialog will have a heading with the version number and a "TEST" marker. When the DLL stops working, please copy back your backup, or reinstall the product via DIM.
    4. This is beta code. It hasn't gone through Daz testing.
    5. The DLL is for 64-bit Windows only.

    I haven't compiled a detailed change log for this version yet, but I did a lot of testing with multiple instances and rewrote the restart code in that respect, so hopefully this fixes the problems people were having. The new approach is:

    1. The render queue plugin asks Daz Studio to quit (only in "polite" mode);
    2. it starts a batch script which is now much longer and takes four arguments, most importantly the PID of the DazStudio.exe process that the RQ was running in; the new batch script then waits for that process to exit and kills it after a configurable timeout (by default, 60 seconds);
    3. the batch script then relaunches Daz Studio.

    If this sounds complicated, the TL;DR is it should work out of the box on all systems without configuration. :-)

    This new approach also works when multiple instances are open; the Render Queue correctly stops and restarts the primary instance and leaves the secondary ones alone.

    I'd be grateful for feedback whether this works better. Thank you for testing!

    Post edited by ManFriday on
  • Hello @ManFriday,

    a first initial test with four simple scenes worked fine! During the week I will prepare a test with more scenes. I think I'll get this done until wednsday. I will report then. Thanks a lot for you effort!

    Best regards

     

  • JamieMJamieM Posts: 353
    edited November 2020
    ManFriday said:
    EDITED

     

    Post edited by JamieM on
  • JamieMJamieM Posts: 353
    JamieM said:
    ManFriday said:

     

    The link just leads me to a picture of a cloud with an M in a circle.  No download link. 

    (Seems to be "Mega Privacy" in New Zealand ???)

     

     

  • JamieMJamieM Posts: 353

    ... but now it IS working! Thanks!

  • Hello @ManFriday,

    I now also finished my second test, consisting of five more complex scenes. And it worked like a charm.

    Is there anything in particular you want to have tested?

    Best regards

  • JamieMJamieM Posts: 353

    I have owned render queue for over a month. Up till now I haven't had a single success - with every attempt failing after the first render - even when folowing your advice re settings.

    Yesterday i downloaded and used the new dll and then I tested it overnight with a queue of seven renders - including some quite complex scenes. 

    This morning - TA-DA - perfect - all seven had rendered and saved without problem. 

    Thank you! On a first test, this fix really seems to do the trick.

    One thing: I'm a bit puzzled about the timings listed - it seems implausible that the fairly complex scenes 6 and 7 (inlcuding strand-based hair on an AM animal) rendered in 2 or 4 minutes - so I wonder if the time reporting is accurate.

    But - main thing - it works - and it's now doing what it says on the tin.

    Thank you.

    render queue list.PNG
    134 x 267 - 6K
  • JamieM said:

    I have owned render queue for over a month. Up till now I haven't had a single success - with every attempt failing after the first render - even when folowing your advice re settings.

    Yesterday i downloaded and used the new dll and then I tested it overnight with a queue of seven renders - including some quite complex scenes. 

    This morning - TA-DA - perfect - all seven had rendered and saved without problem. 

    Thank you! On a first test, this fix really seems to do the trick.

    One thing: I'm a bit puzzled about the timings listed - it seems implausible that the fairly complex scenes 6 and 7 (inlcuding strand-based hair on an AM animal) rendered in 2 or 4 minutes - so I wonder if the time reporting is accurate.

    But - main thing - it works - and it's now doing what it says on the tin.

    Thank you.

    Did you check the last 2 renders? Did they seem to render properly? Maybe there is something in the render settings e.g. max render time, etc? You can also look in the DS log, the timings should be in there as well.

  • JamieMJamieM Posts: 353
    JamieM said:

    I have owned render queue for over a month. Up till now I haven't had a single success - with every attempt failing after the first render - even when folowing your advice re settings.

    Yesterday i downloaded and used the new dll and then I tested it overnight with a queue of seven renders - including some quite complex scenes. 

    This morning - TA-DA - perfect - all seven had rendered and saved without problem. 

    Thank you! On a first test, this fix really seems to do the trick.

    One thing: I'm a bit puzzled about the timings listed - it seems implausible that the fairly complex scenes 6 and 7 (inlcuding strand-based hair on an AM animal) rendered in 2 or 4 minutes - so I wonder if the time reporting is accurate.

    But - main thing - it works - and it's now doing what it says on the tin.

    Thank you.

    Did you check the last 2 renders? Did they seem to render properly? Maybe there is something in the render settings e.g. max render time, etc? You can also look in the DS log, the timings should be in there as well.

    Yes - the renders produced perfect images. The attached is a small part of the "4.03" minute one. This is an image I would normally expect to take at least 50 minutes - or more like 90!

    I can't make head or tail of the log. It seems to be filled with a huge number of "WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): Got an unknown command from the persistent connection: " but no clear log of renders.

     

     

    mouse.PNG
    474 x 220 - 232K
  • JamieM said:
    JamieM said:

    I have owned render queue for over a month. Up till now I haven't had a single success - with every attempt failing after the first render - even when folowing your advice re settings.

    Yesterday i downloaded and used the new dll and then I tested it overnight with a queue of seven renders - including some quite complex scenes. 

    This morning - TA-DA - perfect - all seven had rendered and saved without problem. 

    Thank you! On a first test, this fix really seems to do the trick.

    One thing: I'm a bit puzzled about the timings listed - it seems implausible that the fairly complex scenes 6 and 7 (inlcuding strand-based hair on an AM animal) rendered in 2 or 4 minutes - so I wonder if the time reporting is accurate.

    But - main thing - it works - and it's now doing what it says on the tin.

    Thank you.

    Did you check the last 2 renders? Did they seem to render properly? Maybe there is something in the render settings e.g. max render time, etc? You can also look in the DS log, the timings should be in there as well.

    Yes - the renders produced perfect images. The attached is a small part of the "4.03" minute one. This is an image I would normally expect to take at least 50 minutes - or more like 90!

    I can't make head or tail of the log. It seems to be filled with a huge number of "WARNING: ..\..\..\..\..\src\sdksource\cloud\dzcloudtasknotifier.cpp(178): Got an unknown command from the persistent connection: " but no clear log of renders.

    You could always load that scene and render it normally and see how long it takes.

  • JamieMJamieM Posts: 353

    My second test was with five renders - all worked perfectly.

    My third test of three renders did two fine but failed on the third one with a fatal error at the start.

    I suspect this may be a bug with Daz Studio 4.14 rather than Render Queue as this has happened a few times when doing normal rendering.

    If anyone can interpret the log I'd be glad to know what the problem is!

    Also what are all these "unknown commands from persistent connection" entries? My log is full of them.

     

     

    fatal 3.PNG
    1920 x 696 - 120K
  • JamieM said:

    My second test was with five renders - all worked perfectly.

    My third test of three renders did two fine but failed on the third one with a fatal error at the start.

    I suspect this may be a bug with Daz Studio 4.14 rather than Render Queue as this has happened a few times when doing normal rendering.

    If anyone can interpret the log I'd be glad to know what the problem is!

    Also what are all these "unknown commands from persistent connection" entries? My log is full of them.

    The Iray errors seem to indicate that you ran out of VRAM -- the scene is too big for your card. Probably unrelated to the Render Queue unless you can render the scene fine without it.

    The others seem to be hickups from Daz Studio trying to talk to the servers at daz3d.com, probably related to Daz Connect? I would recommend disabling auto-logon with Daz Connect while using the Render Queue because failures to connect to Daz after the Render Queue has restarted Daz Studio will stall everything.

  • JamieMJamieM Posts: 353
    ManFriday said:
    JamieM said:

    My second test was with five renders - all worked perfectly.

    My third test of three renders did two fine but failed on the third one with a fatal error at the start.

    I suspect this may be a bug with Daz Studio 4.14 rather than Render Queue as this has happened a few times when doing normal rendering.

    If anyone can interpret the log I'd be glad to know what the problem is!

    Also what are all these "unknown commands from persistent connection" entries? My log is full of them.

    The Iray errors seem to indicate that you ran out of VRAM -- the scene is too big for your card. Probably unrelated to the Render Queue unless you can render the scene fine without it.

    The others seem to be hickups from Daz Studio trying to talk to the servers at daz3d.com, probably related to Daz Connect? I would recommend disabling auto-logon with Daz Connect while using the Render Queue because failures to connect to Daz after the Render Queue has restarted Daz Studio will stall everything.

    I did successfully render the scene withot problems straight after. But I suspect DS rather than Render Queue for the problem.

    Thanks for the advice re Daz connect (which I don't use). I'll try your suggestion.

  • barbultbarbult Posts: 23,050

    You might also want to uncheck the option to participate in the improvement program. That is another source of connecting to Daz over the Internet. I don't know if it affects the Render Queue operation, though.

     

    Screenshot 2020-11-19 132158.png
    475 x 579 - 39K
  • JamieMJamieM Posts: 353

    Thanks barbult. 

    Is the Auto-logon that ManFriday refers to The Login option at the top of the Connect menu bar?

     

  • barbultbarbult Posts: 23,050
    JamieM said:

    Thanks barbult. 

    Is the Auto-logon that ManFriday refers to The Login option at the top of the Connect menu bar?

    Yes, I believe so. If you login there, it gives you a checkbox to let you select to automatically login in the future.

  • JamieMJamieM Posts: 353

    Thanks! I've followed all advice. The warnings seem to have stopped.

  • JamieMJamieM Posts: 353

    I've done a number more render queues. All have worked successfuly.

    This add-on has changed my whole way of working. I can now work on design through the day - with only short test renders - and leave the donkey work to overnight. This is why I bought the program in the first place - and it is now doing exacyly what I need.

    A game-changer for me. Thank you ManFriday.

  • I might be missing it, but is there an option anywhere to render directly to file rather than having it render to a new window? For some scenes rendering direct to file works fine, but if I try to render to new window then it pushes the VRAM over the edge.

  • BD2021 said:

    I might be missing it, but is there an option anywhere to render directly to file rather than having it render to a new window? For some scenes rendering direct to file works fine, but if I try to render to new window then it pushes the VRAM over the edge.

    I'm afraid there is no such option, sorry!

  • I have submitted the update to Daz, finally, so hopefully it'll be out soon.

  • JamieMJamieM Posts: 353
    ManFriday said:

    I have submitted the update to Daz, finally, so hopefully it'll be out soon.

    Hurray! Thanks

     

  • JamieMJamieM Posts: 353

    I wanted to do a render queue tonight but your time-bombed version has expired. No sign of the official update yet . (Eleven days to approve it???)

    Um ...

  • Any chance having a macOS version in the not-so-far future? Like Mesh Grabber? I LOVE that tool :-)

  • JamieM said:

    I wanted to do a render queue tonight but your time-bombed version has expired. No sign of the official update yet . (Eleven days to approve it???)

    Um ...

    Yes, it's still in the queue at Daz. Sorry!

  • Mark_e593e0a5 said:

    Any chance having a macOS version in the not-so-far future? Like Mesh Grabber? I LOVE that tool :-)

    Thank you! A Mac version of the Render Queue is very unlikely though because unlike Mesh Grabber, the Render Queue has a lot of Windows-specific code in it.

Sign In or Register to comment.