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
That's a question for @G3Renderworks.
The plugin was already installed when I installed the beta. Some stuff was working out of the box but others, like this and mesh grabber, didn't.
The beta needs to be installed before the plugin, so DIM has a place to put the plugin for the beta. If you installed the plugins before you had ever installed a beta, that would explain why the plugin was not available in the beta, because when you installed the plugin, there was no DAZStudio4 Public Build directory on your computer for DIM to put the plugin into. Reinstalling the plugin with DIM after installing the beta should have worked.
I didn't even think to try because that's what I did with mesh grabber and it still didn't work. It only worked after there was a beta update.
That's a mystery. At least you got it resolved now.
Since you mentioned this in the Seamster thread, I found this post now but it seems that nobody except you is having this problem. This is why I didn't reply before. I use the Render Queue for all my renders myself and would surely have noticed the problem.
If there is a step-by-step scenario that I can try to reproduce, or maybe post a simple sample scene here that doesn't use any exotic products that I can try to load myself, I can have a look.
It would really be more helpful if you could name at least one clothing item which exhibits the problem.
It happend to every clothing inside my Daz version.
4.20
TLDR version: I see no problem with Render Queue 3 and Mesh Grabber in 4.22.1.74 Public Build.
I'm using Render Queue 3 in Windows 10 and DS version 4.22.1.74 Public Build (beta). I don't have any version as old as 4.20 installed to test with. I loaded Twiggant and the G9 Base Shirt. There is a huge amount of poke through because Twiggant is a very exaggerated shape. I saved the scene. Then I used Mesh Grabber to conquer the poke through. I saved a second scene. I queued both scenes up in Render Queue 3 and rendered the queue. I also rendered the scene with Mesh Grabber without Render Queue 3, just normal render. There was no problem. The Mesh Grabber scene rendered with Render Queue 3 was exactly like the scene rendered with the normal Daz render.
G9 Base Shirt on Twiggant - no Mesh Grabber Applied
G9 Base Shirt on Twiggant - Mesh Grabber applied and rendered with Mesh Grabber 3
G9 Base Shirt on Twiggant - Mesh Grabber applied and rendered with normal Daz Studio render
Meshgrabber is NOT affected, I talked about smoothing modifier, also I don't can load G9 stuff in 4.20 :)
I made now a test and ofc... NOW it worked xD maybe it's buggy when the scene has multiple chars+environment?
I misunderstood. Are you really using Render Queue 3? In my Twiggant example above, smoothing was on, and it worked fine in Render Queue 3. There was a problem in the original Render Queue product, with smoothing being changed by the plugin, if I recall correctly. This was resolved in Render Queue 3, along lots of other enhancements. If you are not using Render Queue version 3, I think you need to upgrade to solve your problem.
Yes V3.0.16
I just build up a larger scene to test it. My last test war G8M with basic wear.
I can't reproduce it in my test settings now -.-.... I don't understand this :(
I build a room, G8F + G8M + dforce clothing, used meshgrabber to cause bugs, used smoothing modifier to smooth it and it stayed smooth when I rendered...
I don't know why this doesn't happen now ;(
I have come across a "weird behaviour" of RQ3, only occuring when restarting Daz Studio after X renders, but only in mode "render all visble cameras", not in render specific cameras!
Daz Studio Version is 4.22.0.16 and RQ V3.0.16. Situation is the same on two PC instances, both Win11.
When setting up RQ 3 not to restart, everything work fine. When rendering a number of visible cameras in a scene, i.e. 20 and restarting after X renders, the first X renders are saved correctly to the output directory. After the first restart, the filename displayed by RQ in its status window is "" (empty string included in paranthesis) and hence no output file is written. (The Render Queue was saved as "RQ.rq.json"). For some reason, in the mode "render all visible cameras" RQ seems to "forget" the filename. It should be the name of the scene with camera name appended, but that is only the case for the first X renders. After restart, this logic fails apparently. It also does not occur when rendering specific cameras!
Has anybody experienced similar issues or can replicate this?
Before I continued troubleshooting, I re-installed the Plugin via DIM (with Daz closed) to make sure there is no corrupt DLL or anything like this going on.
I have found this issue to be a special case / variation of what was flagged by @OdinVonD and discussed by @barbult in Oct 2023:
After the first restart of Daz Studio after a set number of renders, the camera is switched to "Perspective View" and the output file name is set to "C:\Users\XXXXX\AppData\Roaming\DAZ 3D\Studio4\temp\render\r.png" and hence constantly overwritten when a scene/camera is rendered. This is interrupted only to render the Scene Icon (91x91px) and Tip (256x256px) files, which works correctly.
After that, persective view is used again and output filename ...\Studio4\temp\render\r.png
To allow reproduction of the error, I have created the most simple scene I can think of: a coloured cube with six cameras and saved that as three versions with red, green and blue surfaces to individual files. Added those three scenes to RQ3 with "render all visible cameras" + icon + tip and set to restart after 4 renders. log.txt is included to confirm problem description above.
Thank you for your efforts to give me something I can try to reproduce. I will try this out!
I've been getting the mesh smoothing bug when rendering an animation, as mentioned a few pages back the frames are not allowed to settle down before rendering, it just skips to the specified frame and starts rendering.
Steps to reproduce:
1. Add a figure with clothing that has poke-through
2. Add a smoothing modifier to clothing
3. Render Animation in render queue 3 for more than one frame
4. Mesh smoother applies on the first frame, but not the rest of the frames
Hi, I love this product, but I'm having problems with the character's skin. Randomly, when using render queue 3 to render animations, the glossiness of the character's skin is being turned off. It happens very often and it's very annoying. It never happened to me before until I started using this render queue. So, if I render 30 frames in a night, 5 of them might end up with no glossiness.
It has happened to me with two different PCs, both with nice specs and with the same issue. (I upgraded from one PC to the other.)
One was an RTX 3060 and the other one a Ryzen 7 with a 4070. Both PCs have the same problem.
So, I really don't know which setting is incompatible with this queue.
In the renders, slowly the glossiness of the character's skin starts to fade after each frame until it disappears completely.
This issue occurs when rendering animations. My main advantage of using this queue was being able to render animations, but I hate having this problem.
Hi, I've noticed that Daz by default has some problems when it cleans the scene instead of restarting. Is there not an option to restart Daz after each scene is finishe rather than after a certain amount? I really feel that this would fix a lot of problems with this script, as when people reset the scene after a certain number of renders, it tends to break the smoothing and ignore it.
Would it be difficult to make that a feature? Making it restart after each scene ends. I would really be happy if it could, even paying for it if you need.
The existing options in Render Queue 3 allow you to configure it to restart Daz Studio after each render. Is that what you are looking for, or do I misunderstand? I'm not clear on what you mean about restarting after each "scene" and what you mean by "after a certain amount" (amount of what?).
A similar character skin problem during animation was reported by another user here. That report had no mention of using Render Queue 3 when this problem occurred. However, it is possible that he just didn't mention it. Maybe the two of you should "talk" and see if you can determine whether you have the same problem or not. That might help get it resolved.
Thanks so much. Yeah, it seems they are having the same problem. Also, what I meant by restarting after each file is that I meant restarting after all the renders of a file were finished, rather than after a certain amount of renders.
But I have not seen that setting anywhere. It would really be useful to have a setting that allows the render queue to restart after each file has finished. I don't restart after a certain amount as you suggested because that breaks the smoothing modifier. A lot of people seem to have that problem, so if Daz instead restarted just each time loading a new file, that would be extremely helpful in avoiding bugs and also saving VRAM.
I haven't seen a problem with "breaking the smoothing modifier" in version 3 of Render Queue. Are you setting the various delay times in the configuration parameters high enough to let the scene settle before it starts rendering?
Yes, I give enough time. but something I don't understand is the problem with the breaking skin mats problem, it happens every day, have you not able to recreate the issue? It even happens at frame 0. Something in render queque 3 breaks pbr skins similar to that post you sent me. But I don't have that problem with other render queque, just this one. I could renders without any problem with other render queque. I like this one because it allows animations but it's not use as it has chance to break them.
you really don't see differences on the lighting between rendering? It has chances to behave very strange with this script.
I really can't work with this render queque, I've been trying to make it work right for months, Never had problem with other renders queque. The problem is because as this load other scene rather than restarting it cause problems with memory. I really don't understand why manfriday did not add a setting to restart after each scene has finished as other render queque sofwares do.
Problem with restarting after each render is it breaks their smoothing.
My problem is easy to recreate, just load several scenes without restarting daz, specifically ones with hdri and a character pbr skin and you will notice the fatige. . Maybe you are not using pbr skins or the timeline to render so you do not notice it.
Please just add a choice to restart daz after an scene ends as other render queques do. Manfriday wrote he did not do that because he though it was useless but he was wrong about that, daz needs to restart. As I said the fatigue is visible with pbr skins. This queque is also completly useless to render several animations as it breaks them.
Being able to restart the scene after an scene ends will completly negate a lot of bugs and problems as it would be the natural way to use daz, I'm saying after finishing an scene not render as I think you are getting confused there.
My theory about the smoothing modifier problem is you added a maximun time but not a minimun, you should have added a minimun as even if I put 120 seconds for the scene to settle down, after loading the scene ignores the timer, so smoothing has not time to settle. That is 100% the reason. I remind you, this happens when you render using the timeline as an animations. a lot of people build their scenes in the timeline there is when this queque stop working properly.
Just do the test, it's very easy, load an animation with smoothing on the character and set render queque to render after each one. you will see how unstable the smoothing becomes.
Also I've reninstalled and clean the folder over and over to check if it was a corrupt DLL but I still have the same.
Edit: I meant smoothing, I wrote d-force by accident, I just corrected it.
Wow that sounds amazing, would you mind sharing or selling that for my own use? As I do the same to avoid any sort of problem. As the problem with this queque is when you do animations or use the timeline.
And saving each scene one by one takes a long time, especially because I generate around 300 renders per month so that script would really save me a lot of time and pain.
Otherwise thanks for letting me know I can make or get an script like that.
Sure, I tried attaching the script here but the site wont let me, so I will upload it to renderosity and notify you when it gets approved.
Thanks so much, that'd be amazing! And it will help me a lot in my work.