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
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.